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Division  of  the  Command  and  Control  Office  of  CNO  (OP-945),  and  managed  by  the 
Naval  Data  Automation  Command  (NAVDAC). 

This  is  the  second  report  addressing  the  development  of  a  command-level 
decision  support  system  workstation  for  BASIS.  The  methodology  and  results  presented 
here  are  intended  to  assist  BASIS  developers  in  meeting  their  goals  of  providing  a  user- 
friendly  system  that  employs  current  technology  and  state-of-the-art  equipment.  The 
development  methodology  discussed  here  is  applicable  to  the  development  of  decision 
support  systems  for  other  computer-based  information  systems.  The  preparation  of  this 
report  was  supported  by  funding  from  NAVDAC. 
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SUMMARY 


Problem 

Effective  management  of  complex  operations  such  as  Navy  bases  and  stations 
requires  maintenance  of  and  ready  access  to  massive  amounts  of  information.  The  Bases 
and  Stations  Information  System  (BASIS)  is  a  computer-based  network  currently  under 
development  to  fulfill  the  command  staffs  need  for  timely  and  accurate  information 
concerning  base/station  activities.  BASIS  developers  are  striving  to  deliver  a  system  that 
interfaces  with  the  several  standard  management  information  systems  (MIS)  already 
mandated  by  various  functional  area  sponsors.  BASIS  is  to  be  a  major  information 
trunkline  that  allows  users  to  share  information.  All  this  must  occur  in  a  "user-friendly" 
environment  in  which  the  operation  of  the  system  is  easy  to  learn,  easy  to  use,  and 
powerful  enough  to  meet  a  significant  portion  of  the  user's  demands  for  information. 

This  research  effort  focuses  on  an  important  component  of  BASIS,  namely,  the 
methods  by  which  decision  support  capabilities  for  base  and  station  command  staffs 
ought  to  be  developed.  Such  methods,  if  successful,  should  apply  to  a  wide  range  of 
information  systems  for  relatively  unsophisticated  computer  operators  who  require  the 
aid  of  automated  systems  for  a  broad  range  of  decision  making. 

Purpose 

The  primary  purpose  of  the  overall  effort  is  to  provide  decision  support 
capabilities  through  BASIS  to  COs,  XOs,  and  department  heads  of  Navy  bases  and 
stations  to  aid  them  in  fulfilling  their  job  responsibilities.  The  goals  of  this  phase  of  the 
project  were  to:  (1)  develop  a  methodology  for  designing  decision  support  systems  (DSS) 
for  naval  commanders,  and  (2)  apply  this  methodology  within  the  BASIS  development 
effort. 


Several  subgoals  were  pursued:  (1)  to  determine  the  scope  of  job  responsibilities 
of  department  heads  of  Navy  bases  and  stations,  (2)  to  ascertain  what  important 
department  head  tasks  would  be  the  most  amenable  to  computer-based  decision  support, 
(3)  to  assess  the  feasibility  of  providing  department  heads  with  generic  decision  support 
tools  applicable  to  a  wide  range  of  problems  and  tasks,  and  (4)  to  identify  department 
performance  indicators  that  could  be  used  in  evaluating  the  impact  of  introducing  an 
MIS  or  DSS  into  the  organization. 

DSS  Development  Approach 

A  user-oriented  model  of  DSS  development  was  synthesized  for  the  present 
effort.  This  model  consists  of  several  discrete  phases  and  steps:  (1)  decision  task 
analysis,  (2)  selection  of  decisions  to  support,  (3)  descriptive  analysis  of  decision 
processes,  (4)  conceptual  definition  of  DSS,  (5)  development  and  integration  of  tools,  and 
(6)  test  and  revision.  The  first  three  steps  comprise  a  requirements  definition  phase. 

The  next  two  steps  make  up  a  design  and  development  phase.  The  final  phase 
encompasses  operational  test  and  revision  of  the  DSS. 


Approach 


A  computerized  job  task  analysis  relevant  to  department  heads  of  Navy  bases  and 
stations  was  developed.  Department  heads  rated  the  frequency  and  importance  of  70  job 
tasks  that  could  be  computer  aided  in  meeting  their  job  responsibilities.  Upon 
completion  of  the  task  analysis,  department  heads  were  asked  several  open-ended 
questions  concerning  computer  equipment  currently  in  their  departments,  present  needs 
in  terms  of  computer  and  decision  support,  and  measures  they  use  to  gauge  the 
performance  of  their  departments. 

Results 

Eighty-two  interviews  were  conducted  at  16  Navy  commands.  Results  from  the 
job  task  analysis  are  presented.  The  job  task  frequency  and  importance  ratings  were 
compared  across  departments  and  across  command  types.  Almost  all  department  heads 
felt  that  computerization  would  improve  the  performance  of  their  departments.  The 
majority  of  the  departments  function  with  little  or  no  computer  automation.  Even 
without  exposure  to  the  range  of  computer  system  capabilities,  department  heads  were 
articulate  in  expressing  the  many  needs  that  could  be  met  by  computer  support.  These 
are  summarized.  At  the  same  time,  department  heads  expressed  concern  about  the 
development  of  competing  systems,  and  the  inability  of  systems  to  integrate  with  one 
another.  Department  performance  indicators  are  also  suggested  for  future  evaluation 
efforts. 

Discussion  and  Conclusions 

Analysis  of  the  task  rating  data  shows  department  heads  of  Navy  bases  and 
stations  to  be  a  reasonably  homogeneous  group  of  target  users  who  could  benefit  greatly 
from  a  DSS  that  provides  generic  tools  for  data  display,  manipulation,  and  analysis.  In 
addition,  the  user-oriented  model  of  DSS  development  described  in  this  report  provided 
a  useful  framework  for  guiding  the  initial  efforts  of  DSS  design.  It  is  recommended  that 
future  development  efforts  adopt  this  or  a  similar  methodology.  This  DSS  development 
model  ensures  that  the  product  is  user-defined,  user-specified,  and  user-evaluated.  This 
type  of  involvement  between  developers  and  users  throughout  the  design  process  is 
critical  to  system  acceptance  and  success. 
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INTRODUCTION 


Problem 

Effective  management  of  complex  operations  such  as  Navy  bases  and  stations 
requires  maintenance  of  and  ready  access  to  massive  amounts  of  information.  Because 
of  the  tremendous  responsibilities  and  costs  associated  with  the  effective  operation  of 
Navy  bases  and  stations,  OP-945  is  sponsoring  an  effort  to  provide  managers  with 
modern  information  management  capabilities.  The  system  under  development  is  a 
computer-based  network  known  as  the  Bases  and  Stations  Information  System  (BASIS). 

It  is  designed  to  fulfill  the  command  staffs  need  for  timely  and  accurate  information 
concerning  base/station  activities.  BASIS  will  ultimately  become  a  management 
information  system  (MIS)  supporting  at  least  16  functional  areas  typical  of  base/station 
management  and  operation. 

BASIS  developers  are  striving  to  deliver  a  system  that  can  interface  with  several 
standard  information  systems  already  in  place  (e.g.,  IDFMS,  PASS/SDS,  BEST).  BASIS 
is  to  be  a  major  information  trunkline  that  allows  users  to  access  information  from  and 
transmit  it  to  others  who  may  be  located  elsewhere.  The  integrity  of  the  source  files  and 
of  security  requirements  for  access  to  specific  information  is  to  be  preserved.  All  this 
must  occur  in  a  "user-friendly"  environment  in  which  the  operation  of  the  system  is  easy 
to  learn,  easy  to  use,  and  powerful  enough  to  meet  a  significant  portion  of  the  user’s 
demands  for  information. 

This  effort  focuses  on  an  important  component  of  BASIS,  namely,  the  methods 
by  which  decision  support  capabilities  for  base  and  station  command  staffs  ought  to  be 
developed.  Such  methods,  if  successful,  should  have  applicability  to  a  wide  range  of 
information  systems  that  are  used  by  relatively  unsophisticated  computer  operators  who 
require  the  aid  of  automated  systems  for  decision  making. 

Purpose 

The  primary  purpose  of  the  overall  effort  is  to  provide  decision  support 
capabilities  through  BASIS  to  COs,  XOs,  and  department  heads  of  Navy  bases  and 
stations  in  fulfilling  their  job  responsibilities.  The  goals  of  this  phase  of  the  project 
were  to  develop  a  method  for  designing  decision  support  systems  (DSSs)  for  naval  base 
and  station  commanders  and  to  implement  this  method  within  the  BASIS  development 
effort.  In  an  earlier  investigation  (Stuster,  Casey,  Dick,  &  Moy,  1987),  the  needs  of 
commanding  officers  (COs)  and  executive  officers  (XOs)  of  base  and  station  commands 
were  addressed.  What  remained  was  to  determine  decision  support  capabilities  that  could 
serve  the  next  echelon  of  command--the  department  heads. 

Several  specific  subgoals  were  pursued:  (1)  to  determine  the  scope  of  job 
responsibilities  of  department  heads  of  Navy  bases  and  stations,  (2)  to  ascertain  what 
important  department  head  tasks  would  be  the  most  amenable  to  computer-based 
decision  support,  (3)  to  assess  the  feasibility  of  providing  department  heads  with  generic 
(broadly  applicable)  decision  support  tools,  and  (4)  to  identify  department  performance 
indicators  that  could  be  used  in  evaluating  the  impact  of  introducing  an  MIS  or  DSS  into 
the  organization. 


BACKGROUND 


DSS  Design 

Computer  systems  provided  to  managers  are  typically  database  management 
systems  that  may  contain  millions  of  data  points,  but  provide  only  a  limited  means  of 
querying  the  system  for  information.  Most  often  there  is  only  the  capability  of 
producing  a  number  of  marginally  informative,  standard  reports.  The  breadth  and 
formatting  of  the  available  information  and  reports  are  built  in  anticipation  that  the 
requester  will  be  using  the  information  in  a  well-defined  manner.  These  systems  are 
commonly  referred  to  as  management  information  systems  (MIS),  although  the  range  of 
capabilities  of  MISs  vary  tremendously. 

As  information  systems  become  more  common  in  businesses  and  as  computer 
technology  becomes  more  sophisticated,  managers  are  requesting  more  from  systems  than 
the  mere  display  and  printing  of  information.  Tne  users  are  becoming  more 
sophisticated  and  creative  about  what  is  possible  with  the  information  they  know  is 
available  in  the  computer.  They  are  asking  for  more  computer-based  tools  to  assist  them 
with  the  decision  making  process.  They  find  standard  reports  are  not  sufficient  for 
handling  novel  situations.  The  users  want  to  be  able  to  easily  formulate  ad  hoc  queries, 
to  ask  "what  if"  questions,  and  to  massage  information  into  a  more  useful  form  than 
homogeneous  line  printer  reports.  Systems  designed  to  address  these  requirements  are 
usually  referred  to  as  decision  support  systems  (DSS). 

Support  for  managers  is  the  overriding  concern  in  all  DSS  development  efforts. 
Nevertheless,  many  DSSs  have  come  under  severe  criticism  by  managers  and  have  been 
discarded  or  ignored.  Partow-Navid  (1987)  has  outlined  many  reasons  why  DSSs  fail, 
including:  ( 1 )  incompatibility  between  DSS  and  end-user  needs,  (2)  failure  to  define 
accurate,  feasible  goals,  (3)  the  use  of  unrealistic  or  invalid  models,  (4)  inadequate 
integration  of  tools  handling  aspects  of  a  decision  into  a  comprehensive  model  dealing 
with  all  parts  of  the  decision,  and  (5)  failure  to  secure  user  satisfaction  through  lack  of 
user  involvement  in  the  development  process.  How  one  goes  about  designing  a  DSS  that 
meets  end-user  needs  and  avoids  these  pitfalls  has  been  strongly  debated.  Yet  there  is 
general  agreement  that  the  need  for  DSS  is  genuine. 

Nutt  (1986)  separates  the  MIS/DSS  development  approach  into  two  crucial  steps: 
(1)  identifying  key  activities  of  users  and  (2)  specifying  the  information  necessary  to 
perform  these  activities.  Although  skepticism  exists  concerning  the  ability  of  users  to 
assist  in  the  development  process,  Nutt  supports  the  idea  that  managers  themselves  can 
specify  information  requirements  and  assist  in  the  development  of  an  MIS/DSS. 

King  and  Cleland  (1975)  outline  several  steps  to  follow  in  developing  a  DSS. 

They  term  their  methodology  "decision-oriented,”  and  recommend  that  developers: 

(1)  identify  decision  areas  based  on  existing  theory  and  interviews  with  appropriate 
managers,  (2)  define  these  decision  areas,  (3)  develop  a  descriptive  model  of  the  system, 
(4)  develop  normative  (ideal)  and  consensus  models  of  the  system,  and  (5)  specify 
decision  criteria  and  information  requirements. 

Stabel!  (1983)  concurs  with  the  decision-oriented  approach.  He  states  that  there 
are  two  aspects  of  the  decision  process  that  must  be  understood.  One  is  the  substantive 
aspect,  or  the  "what"  of  a  decision.  The  other  is  the  procedural  aspect,  or  the  "how"  of  a 
decision.  Stabel!  concludes  that  DSS  developers  need  "decisional  imagination,"  or  the 
ability  to  produce  a  working  diagnosis  of  the  what  and  how  of  a  decision  after  limited 
exposure  to  a  decision  situation. 
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By  virtue  of  their  focus  on  decisions,  many  DSS  developers  acknowledge  the 
need  to  integrate  a  decision  analysis  approach  with  their  DSS  development  method.  A 
decision  model  commonly  applied  to  DSS  development  is  that  of  Simon  (1960),  who 
discusses  decision  making  in  terms  of  three  stages:  (1)  intelligence— searching  the 
environment  for  conditions  requiring  a  decision,  (2)  design- -developing  and  analyzing 
possible  courses  of  action,  and  (3)  choice— selecting  a  course  of  action  from  those 
available.  Scott-Morton  (1971)  also  applies  decision  theories  to  the  DSS  arena,  resulting 
in  another  analytic  approach  to  DSS  development.  His  approach  recognizes  the  unique 
demands  of  semi-structured  or  unstructured  decisions,  and  suggests  this  is  where  DSSs 
can  have  their  most  beneficial  impact. 

An  issue  that  has  received  much  attention  in  the  DSS  development  area  is  that  of 
individual  differences  and  the  impact  of  personal  and  cognitive  styles  on  DSS  design  and 
usefulness.  It  may  be  necessary  to  build  a  flexible  system  that  can  accommodate  a  wide 
range  of  styles.  This  requirement  is  not  always  supported  in  research  findings,  however. 
Huber  (1983)  suggests  that  style  may  not  be  a  critical  moderating  variable  in  DSS 
development.  Nutt  (1983)  found  that  managers’  information  preferences  were 
determined  more  by  task  conditions  (such  as  decision  stage  and  decision  familiarity)  than 
by  cognitive  styles  or  personal  preferences  of  the  individuals.  Since  task  conditions  are 
likely  to  be  more  homogeneous  than  the  cognitive  styles  of  individuals  performing  the 
tasks,  this  research  suggests  that  the  development  process  may  be  more  manageable  than 
was  previously  thought.  Nonetheless,  not  all  possible  task  conditions  can  be  anticipated 
either. 

Flexibility  to  meet  the  demands  of  novel  and  varied  decision  situations  and  users 
may  be  a  key  to  DSS  success.  One  implementation  of  a  flexible  DSS  is  described  by 
Carlson  (1983).  He  provides  a  DSS  framework  that  accommodates  a  multitude  of  user 
styles  and  preferences.  This  framework  consists  of  four  components:  (1)  representations 
to  assist  in  conceptualization;  (2)  operations  for  engaging  in  the  decision  processes  of 
intelligence,  design,  and  choice  (Simon,  1960);  (3)  automated  memory  aids;  and  (4)  user 
control  over  the  system.  A  DSS  that  allows  the  user  to  engage  in  operations,  access 
memory  aids,  and  exert  control  over  the  system  through  a  variety  of  alternative 
representations  results  in  a  truly  flexible  DSS. 

Another  issue  implicit  in  the  DSS  design  process  is  decision  optimization.  Most 
DSS  developers  argue  that  the  primary  objective  of  DSS  development  is  to  increase 
decision  making  effectiveness.  Many  DSS  developers  believe  designers  should  provide 
optimal  strategies  for  decision  making  within  a  DSS,  rather  than  provide  only  the 
strategies  that  decision  makers  typically  use.  Optimization  may  be  achieved  by 
comparing  and  contrasting  decision  makers  and  decision  processes  within  a  specific 
context  and  choosing  the  best  strategy  (Stabell,  1983).  Research  in  decision  aiding  has 
consistently  demonstrated  improvement  in  individual  decision  performance  when  aided 
by  systems  predicated  on  analytically  optimal  strategies.  However,  there  is  the 
possibility  of  rejection  of  the  DSS  by  the  user  due  to  the  "unnatural"  process  required  by 
the  optimum  decision  strategy.  Furthermore,  it  might  be  expected  that  an  optimal 
strategy  may  be  specific  to  a  narrow  range  of  tasks,  thus  compromising  the  manager's 
need  for  broadly  useful  decision  support. 

An  issue  that  demands  attention  throughout  the  DSS  design  and  development 
process  is  that  of  the  user-computer  interface.  How  the  end-user  will  access 
information  and  interact  with  the  system  is  a  critical  component  of  DSS  development. 
One  design  goal  is  for  the  query  system  to  be  flexible  enough  to  accommodate  users  with 
a  variety  of  objectives,  experience,  and  personal  styles. 
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Some  of  the  challenges  in  designing  the  interface  for  the  decision 
maker  are  (1)  to  make  him  aware  of  the  types  of  information 
that  are  available,  (2)  provide  the  decision  maker  with  a  means 
to  represent  the  information  in  a  meaningful  form,  (3)  provide  a 
means  for  the  decision  maker  to  operate  on  these  representations, 
and  (4)  to  make  the  mechanics  of  operation  as  transparent  as 
possible  so  that  the  decision  maker  can  concentrate  on  the 
decision  task  rather  than  the  manual  operation  of  the  computer 
system.  (Moy,  1983) 

The  design  of  the  user-computer  interface  has  far-reaching  consequences.  It 
may  have  a  great  deal  of  impact  on  the  total  cost  of  a  computer  system,  since  user- 
friendly  interfaces  may  reduce  training  costs,  which  can  be  a  major  component  in  total 
life  cycle  costs.  In  addition,  an  optimal  interface  may  affect  performance  efficiency  and 
user  acceptance.  Acceptance  may  be  an  especially  important  consideration  in  a  DSS, 
where  users  without  extensive  computer  background  want  to  perform  rather  complex 
operations  in  an  intuitive  way. 

DSS  Development  Approach 

Considering  the  issues  raised  above,  a  user-oriented  model  of  DSS  development 
was  synthesized  for  the  present  effort.  This  approach  is  a  composite  of  techniques 
recommended  by  other  DSS  developers  (King  &  Cleland,  1975;  Nutt,  1986;  Stabell, 

1983),  supplemented  to  address  decision  requirements  faced  by  Navy  base  and  station 
command  staffs.  It  consists  of  several  discrete  phases  and  steps:  (1)  decision  task 
analysis,  (2)  selection  of  decision  tasks  to  support,  (3)  descriptive  analysis  of  specific 
decision  processes,  (4)  conceptual  definition  of  DSS,  (5)  development  and  integration  of 
tools,  and  (6)  test  and  revision  (Figure  1).  The  first  three  steps  comprise  a  requirements 
definition  phase;  the  next  two  steps  are  part  of  a  design  and  development  phase.  The 
final  phase  encompasses  operational  test  and  revision  of  the  DSS. 

Step  1:  Decision  Task  Analysis.  The  first  step,  seen  as  the  core  of  the  DSS 
development  process,  is  to  gain  an  understanding  of  the  user’s  problem  solving  and 
decision  making  responsibilities.  Although  one  could  make  educated  guesses  about 
which  decision  making  aspects  of  the  job  might  benefit  from  assistance,  it  is  best  if  the 
developer  has  first-hand  knowledge  of  what  the  user  does  and  how  he  or  she  does  it. 
Ideally,  the  developer  of  a  DSS  should  begin  system  development  by  working  alongside 
users  to  gain  an  understanding  of  their  job  demands  that  could  be  supported  by  a 
computer.  Short  of  the  ideal,  the  users  may  act  as  informants  in  a  job  task  analysis.  It 
is  difficult  for  developers  to  understand  the  needs  of  users  without  delving  deeply  into 
the  users’  environment  and  collecting  data  that  help  describe  the  demands  placed  upon 
managers.  Data  must  be  gathered  about  the  frequency  and  importance  of  decision  tasks 
and,  if  possible,  the  costs  associated  with  these  tasks. 

Step  2:  Selection  of  the  Decisions  to  Support.  The  next  step  in  the  development 
process  is  to  select  decisions  associated  with  critical  job  tasks  that  could  be  supported  by 
a  DSS.  There  are  several  important  questions  to  answer  in  choosing  decisions  to  support. 
What  decisions  are  being  made  to  accomplish  critical  job  tasks?  Are  decisions  based  on 
information  that  could  be  provided  by  an  MIS?  Could  components  of  this  decision  be 
modeled  on  a  computer  system?  Does  the  user  want  assistance  with  this  decision?  Is  it 
cost-effective  to  develop  a  DSS  component  to  assist  this  decision?  When  selecting 
decisions  to  assist,  the  developer  is,  in  essence,  establishing  the  goals  of  the  DSS.  These 
goals  should  be  discussed  with  users  to  verify  that  the  selected  decisions  are  indeed  ones 
that  users  would  want  to  have  supported. 
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6.  Test  and  Revision 


Figure  1.  DSS  development  approach. 


Step  3:  Descriptive  Analysis  of  Decision  Processes.  The  DSS  developer  next 
documents  the  nature  of  the  existing  processes  for  the  selected  decisions  to  gain  a  more 
complete  understanding  of  the  factors  and  methods  involved.  The  developer  must 
examine  such  things  as  the  type  of  information  required;  how  the  information  is 
currently  handled  and  stored;  the  manner  in  which  users  prefer  to  see  information 
displayed;  methods  by  which  information  is  combined  for  consideration,  decision 
criteria,  and  algorithms;  and  constraints  that  impact  decision  making.  This  examination 
provides  the  DSS  developer  with  both  the  data  element  requirements  and  the  information 
processing  methods  users  apply  in  solving  problems  that  are  data-based.  Analyses  of  this 
data  lead  to  models  of  user’s  cognitive  processes  and  provide  the  basis  for  ideas 
regarding  the  types  of  decision  support  to  be  incorporated  into  the  DSS  design. 


This  completes  the  definition  phase  of  the  DSS  development  process.  The  next 
phase,  design  and  development,  poses  the  challenge  of  matching  user  needs  and 
capabilities  with  computer  technology. 
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Step  4:  Conceptual  Definition  of  the  DSS.  Using  the  information  gathered  in 
the  requirements  definition  phase,  the  DSS  developer  must  create  an  overall  DSS  concept. 
This  concept  should  not  only  focus  on  decision  tasks  to  be  assisted,  but  recognize  the 
user’s  tendencies,  preferences,  capabilities,  and  limitations,  and  matching  them  to  the 
available  information  system/DSS  technology.  Assistance  may  take  several  forms 
depending  on  the  user’s  needs.  For  example,  if  a  decision  process  is  difficult  because 
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the  decision  maker  must  simultaneously  consider  the  exact  values  of  several  variables 
over  a  protracted  period  of  time,  then  display  techniques  might  be  explored  to  aid  the 
user’s  memory.  In  another  case,  if  the  user  must  monitor  data  to  discover  patterns  over 
time,  then  statistical  trend  analysis  tools  could  be  provided.  Patterns  or  relationships 
might  also  be  revealed  by  displaying  information  to  the  user  in  various  ways,  such  as 
through  graphs,  charts,  and  timelines. 


Other  characteristics  of  the  decision  tasks  and  decision  process  must  also  be 
considered  in  the  conceptual  definition  of  the  DSS.  The  definition  should  address  the 
incremental  nature  of  many  decision  processes  and  also  the  fact  that  several  parties  may 
be  involved  jointly  or  sequentially  during  the  decision  process. 


Hardware  and  software  systems  cannot  be  selected  or  developed  independently  by 
the  DSS  designer  because  they  jointly  determine  ultimate  system  capabilities.  For 
instance,  text-oriented  hardware  systems  (and  associated  operating  systems)  constrain  the 
conceptual  definition  of  the  DSS  by  eliminating  the  possibility  of  user-friendly  graphic 
interfaces  and  graphic  information  displays.  Ultimately,  what  should  emerge  from  the 
conceptual  definition  stage  is  a  clear  concept  of  a  managerial  workstation  tailored  for 
decision  support.  Just  as  with  software  development,  the  hardware  specifications  for 
this  workstation  should  emanate  from  prototypes  tested  both  in  the  laboratory  and  in  the 
field. 


One  vehicle  for  refining  the  conceptual  definition  and  translating  it  into  a 
working  form  is  prototyping.  This  is  a  convenient  technique  by  which  design  concepts 
can  be  demonstrated  in  a  concrete  manner.  It  also  provides  a  means  by  which  ideas  can 
be  communicated  between  system  developers  and  system  users.  Prototyping  allows  users 
to  evaluate  ideas  and  provide  feedback  to  developers  on  how  to  modify  their  concepts  to 
more  closely  meet  user  needs.  It  can  ensure  user  evaluation  and  input  throughout  the 
development  cycle.  It  may  also  be  appropriate  at  this  stage  to  evaluate  prototype  models 
experimentally  to  more  precisely  measure  their  impact  on  user  performance  and 
satisfaction. 


Step  5:  Development  and  Integration  of  Tools.  The  conceptual  definition  of 
the  DSS  provides  a  framework  for  breaking  down  the  development  task  into  components 
that  can  later  be  integrated  into  a  complete  DSS.  Initially,  the  developer  may  pursue 
more  detailed  definition  of  prototype  models  of  specific  decision  support  tools  and  aids. 
These  prototype  tools  can  then  be  converted  into  fully  functional  tools  to  assist  users 
with  components  of  the  decision  process.  When  development  of  various  aids  and  tools  is 
complete,  they  can  be  incorporated  into  an  integrated  DSS.  Of  course,  the  DSS  software 
must  have  its  complementary  hardware  in  order  to  be  a  fully  functional  system  that 
provides  the  capabilities  required  in  a  form  acceptable  to  the  users. 


At  this  point  initial  concepts  have  been  translated  into  a  fully  operational  system 
that  can  be  delivered  to  the  user.  However,  a  final  developmental  phase,  operational  test 
and  revision,  is  required  to  verify  whether  or  not  the  system  is  meeting  user  needs  and, 
where  it  is  not,  to  modify  accordingly. 


Step  6:  Test  and  Revision.  Computer  users  have  become  accustomed  to  the  fact 
that  software  and  hardware  are  in  perpetual  evolution.  In  fact,  there  are  instances  when 
initial  users  have  later  come  to  see  themselves  as  beta  (final)  testers  of  new  software  or 
hardware  technology.  Because  the  completion  of  beta  testing  is  an  arbitrary  point  in 
time,  developers  should  deliver  the  DSS  system  to  the  users  with  the  expectation  of 
receiving  feedback  on  its  strengths  and  shortcomings,  which  then  need  to  be  addressed 
by  further  development  efforts  in  order  to  deliver  an  improved  system  at  a  later  date. 


The  Bases  and  Stations  Information  System  (BASIS) 

Managers  of  Navy  bases  and  stations  have  the  responsibility  of  providing  a 
number  of  landlord  functions  for  a  large,  highly  transient  population.  Current 
management  decision  making  procedures  are  not  usually  assisted  by  computers.  BASIS  is 
designated  in  the  Navy  Strategic  Plan  for  Information  Systems,  SECNAV  Notice  5230  of 
27  February  1985,  "as  the  standard  automated  information  system  in  support  of  all  base 
and  station  commanding  officers,  targeting  landlord  functions  and  requirements.”  The 
objective  of  the  BASIS  development  team  is  to  produce  systems  that  will  improve 
management  control,  optimize  productivity,  and  minimize  operating  costs  at  bases  and 
stations. 

In  an  earlier  effort,  the  job  tasks  and  information  requirements  of  COs  and  XOs 
of  U.S.  Navy  bases  and  stations  were  analyzed  to  provide  input  into  the  development  of 
a  DSS  for  BASIS  (Stuster  et  at.,  1987).  It  was  clear  upon  completion  of  that  effort  that 
the  analysis  of  decision  support  requirements  had  to  be  extended  to  the  department  head 
level,  where  many  of  the  daily  decisions  concerning  base/station  functions  are  made  and 
carried  out.  These  top-level  line  managers  are  expected  to  be  the  most  active  users  of 
BASIS. 
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APPROACH 


Subjects 


A  subset  of  Navy  bases  and  stations  was  chosen  as  a  representative  sample  of 
BASIS  users.  Sites  were  selected  to  represent  a  cross-section  of  both  major  command 
types  (naval  stations,  naval  amphibious  bases,  naval  air  stations,  etc.)  and  regions  (West 
Coast,  East  Coast).  The  BASIS  team  contacted  department  heads  representing  six 
functional  areas:  (1)  administration,  (2)  civil  engineering/  public  works,  (3)  comptroller, 
(4)  safety,  (5)  security,  and  (6)  supply.  All  department  heads  in  these  functional  areas 
were  asked  to  participate  in  the  task  analysis  and  interview. 

Automated  Job  Task  Analysis 

The  development  team  adapted  a  procedure  used  by  Stuster  et  al.  (1987)  to 
support  this  effort.  Two  major  changes  were  made  in  the  procedure:  (1)  a  task  set 
appropriate  for  department  heads  was  created,  and  (2)  the  task  rating  procedure  was 
automated  on  a  portable  microcomputer. 

Stuster  et  al.  (1987)  developed  a  set  of  job  tasks  based  on  interviews  with  COs 
and  XOs  of  Navy  bases  and  stations.  This  set  of  job  tasks  was  modified  to  be  relevant 
to  Navy  base  and  station  department  heads  representing  a  variety  of  functional  areas. 
Staff  organization  manuals  (e.g..  Navy  Instruction  5450)  and  manager  position 
descriptions  from  Navy  bases  and  stations  were  used  to  develop  the  new  task  set.  Only 
tasks  amenable  to  MIS/DSS  support  were  included;  a  comprehensive  job  task  analysis  of 
the  six  functional  areas  was  beyond  the  scope  of  this  project.  Task  items  were 
substantially  shorter  than  and  represented  in  number  less  than  two-thirds  of  those  used 
by  Stuster  et  al.  (1987).  The  final  task  set  comprised  70  tasks  (See  Appendix  A). 

A  computerized  item  rating  procedure  was  developed  so  that  the  task  analysis 
could  be  administered  using  a  portable  microcomputer.  All  task  analysis  questions  were 
presented  on  the  computer  screen.  The  subject  responded  by  typing  in  the  appropriate 
number  and  then  pressing  the  return  key. 

Interview  Questions 

Following  the  automated  task  analysis,  subjects  were  interviewed  using  a  semi- 
structured  format.  The  interview  questions  centered  on  three  areas:  (1)  department 
heads’  perceptions  of  BASIS,  (2)  their  interests  and  needs  in  terms  of  MIS/DSS  support, 
and  (3)  department  performance  indicators. 

Procedure 

Interviews  were  scheduled  in  advance  on  a  command  by  command  basis,  usually 
with  the  help  of  a  management  assistant  at  the  command.  The  interviews  lasted  from  60 
to  90  minutes,  and  started  with  a  discussion  of  BASIS  and  the  purpose  of  the  project. 
The  computerized  data  collection  began  with  the  interviewer  entering  a  unique 
identification  number  for  each  department  head  and  the  answers  to  a  series  of 
demographic  questions.  The  questions  concerned  the  size  of  their  departments,  the 
number  of  people  they  supervised,  the  length  of  time  they  had  been  in  their  department 
head  positions,  and  their  experience  with  computers  and  several  kinds  of  software. 

Department  heads  were  then  asked  to  estimate  the  distribution  of  their  time,  by 
percentage,  in  carrying  out  eight  management  functions,  as  identified  by  Mahoney, 
Jerdee,  and  Carrol  (1965)  and  modified  by  Stuster  et  al.  (1987)  for  the  BASIS  effort. 
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The  respondents  were  given  a  worksheet  defining  the  eight  dimensions  (Figure  2).  The 
same  worksheet  was  used  to  record  their  estimates  before  entering  them  into  the 
microcomputer. 


CATEGORIES  OF  COMMAND  TASKS 

Please  estimate  the  proportion  of  your  duty  time  devoted  to  each  of  the  following 
categories  of  management  tasks. 

1.  Planning:  Determining  goals,  policies,  and  courses  of  action.  Work  scheduling,  T 
budgeting,  setting  up  procedures,  setting  goals  or  standards,  preparing  agendas.  [ 


2.  Investigating:  Collecting  and  preparing  information,  usually  in  the  form  of  records, 
reports,  and  accounts.  Inventorying,  measuring  output,  preparing  financial  statements, 
record  keeping,  performing  research,  job  analysis. 


3.  Coordinating:  Exchanging  irtformation  with  people  other  than  subordinates  (such  as 
commanders  of  tenant  commands)  in  order  to  relate  and  adjust  programs.  Advising  other 
departments,  expediting  liaison  with  other  commanding  officers  or  executive  officers, 
arranging  meetings,  informing  superiors,  seeking  the  cooperation  of  other  departments, 
activities,  or  organizations. 


4.  Evaluating:  Assessing  and  appraising  proposals  of  reported  or  observed  performance. 
Officer,  enlistee,  or  civilian  employee  appraisals;  judging  output  records,  judging 
financial  reports,  conducting  facilities  or  personnel  inspection,  approving  requests, 
judging  proposals  and  suggestions. 

5.  Supervising:  Directing,  leading,  and  developing  subordinates.  Counseling 
subordinates,  training  subordinates,  explaining  work  rules,  assigning  work,  handling 
complaints  of  subordinates. 

6.  Staffing:  Maintaining  the  military  and  civilian  work  force  on  the  base  or  station. 
College  recruiting,  civilian  employment  interviewing,  selecting  civilian  employees, 
placing  civilian  employees  and  military  personnel,  assessing  and  recommending 
promorions,  transferring  personnel. 


7.  Negotiating:  Purchasing  or  contracting  for  goods  or  services,  negotiating  for 
facilities,  contracting  suppliers,  dealing  with  sales  representatives,  publishing  general 
information  on  the  facility,  collective  bargaining. 


consultation,  contacts  with  individuals  or  groups  outside  the  organization.  Public 
speeches,  formal  and  informal  public  and  private  gatherings,  community  drives,  news 
releases,  club  meetings. 
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Figure  2.  Categories  of  commead  talks. 
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The  task  analysis  procedure  began  with  respondents  rating  the  frequency  of  the 
70  tasks.  The  first  screen  (Figure  3)  presented  an  example  so  that  respondents  could 
gain  familiarity  with  the  procedure  and  the  rating  scale. 
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Figure  3.  Example  of  frequency  item. 


Upon  completing  the  frequency  ratings,  they  rated  the  importance  of  those  tasks 
that  they  reported  in  the  frequency  ratings  to  have  encountered  in  their  jobs.  Again, 
the  first  screen  provided  an  example  (Figure  4).  Finally,  the  participants  were  asked  to 
provide  a  rough  estimate  of  the  number  of  hours  required  to  complete  each  of  20  tasks 
selected  by  the  investigators.  This  was  done  in  an  effort  to  establish  a  performance 
baseline  to  be  used  in  later  evaluations  of  MIS/DSSs.  Because  of  time  constraints,  data 
on  only  20  tasks  were  collected. 


How  important  do  you  feel  it  if  to  .  .  . 

Track  repair  of  facilitiea  and  equipment? 
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Figure  4.  Example  of  importance  item. 


Upon  completion  of  the  computerized  task  analysis,  respondents  were  asked 
several  open-ended  questions  concerning  the  availability  of  computer  hardware  and 
software,  department  needs  in  terms  of  MIS/DSS,  and  measures  they  use  to  gauge  their 
departments’  performance.  The  interview  was  concluded  with  a  request  for  examples  of 
typical  forms  completed  and  reports  generated  by  the  department. 


RESULTS 


Demographic  Data 

Eighty-two  interviews  were  conducted  at  16  Navy  commands.  The  number  of 
interviews  conducted  by  command  is  presented  in  Table  1. 


Table  1 

INTERVIEWS  BY  COMMAND 


Command  Total 

Naval  Station  (n  =  23) 

Mare  Island  6 

Norfolk  6 

San  Diego  5 

Treasure  Island  6 

Naval  Air  Station  (n  -  26) 

Alameda  4 

Miramar  5 

Norfolk  6 

North  Island  6 

Oceana  5 

Naval  Amphibious  Base  (n  *  10) 

Coronado  5 

Little  Creek  5 

Naval  Medical  Command  (n  -  10) 

Oakland  5 

San  Diego  5 

Naval  Communications  Station,  Stockton  5 

Naval  Training  Center,  San  Diego  5 

Naval  Submarine  Base,  San  Diego  3 
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The  number  of  interviews  conducted  in  the  six  different  departments,  or 
functional  areas,  is  presented  in  Table  2.  At  some  commands  the  department  head 
functions  were  combined,  resulting  in  one  interviewee  representing  two  functional  areas. 
In  these  cases  the  interviewees  were  classified  according  to  their  primary  job 
responsibilities.  The  commands  visited  ranged  in  size  from  small  medical  commands 
(n  *  6)  to  very  large  naval  bases  (n  =  99,000). 


Table  2 


INTERVIEWS  BY  DEPARTMENT 


Department 


Administration 


Civil  Engineering/ 
Public  Works 


Comptroller 


Safetv 


Security 


Supply 


The  majority  of  the  departments  where  interviews  were  conducted  were  headed 
by  military  personnel  (n  =  56),  who  had  been  in  their  positions  an  average  of  2.9  years. 
Table  3  presents  a  summary  of  descriptive  information  on  each  department  or  function. 
The  rank  of  those  interviewed  among  military  personnel  varied  from  chief  warrant 
officer  to  commander,  and  from  GS-lls  to  GS~13s  among  civilian  personnel. 
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Table  3 

DEPARTMENT  CHARACTERISTICS 


Department 

Average 

Size 

Average 
Number  of 
Military 

Average 
Number  of 
Civilian 

Dept 

Head's  Years 
on  Job 

Dept 

Head 

Supervisees 

Administration 

40 

32 

8 

2.4 

7 

Civil  Engineering./ 
Public  Works 

85 

14 

71 

1.5 

5 

Comptroller 

55 

8 

47 

5.4 

4 

Safety 

8 

4 

4 

3.1 

5 

Security 

102 

55 

47 

3.0 

14 

Supply 

165 

86 

79 

1.2 

21 

Average  Overall 

lb 

33 

42 

2.8 

9 

Computer  Experience 


Department  heads  were  asked  to  rate  their  personal  experience  with  computer 
programs  and  applications  on  a  5-point  scale,  from  inexperienced  (0)  to  very 
experienced  (4).  The  results  are  presented  in  Figure  5. 
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Figure  S.  Average  computer  experience  reported  by  department  heads. 
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Department  heads  were  also  asked  if  they  had  personally  used  any  of  four 
different  types  of  software  (word  processing,  database,  spreadsheet,  and  communica¬ 
tions).  The  most  common  type  used  was  word  processing.  Next,  in  decreasing  order  of 
use,  were  database  programs,  spreadsheets,  and  electronic  communications.  Previous 
experience  apparently  varies  in  relation  to  department  activities.  Figure  6  displays 
department  heads’  ratings  of  computer  software  use. 

Department  heads  were  asked  if  they  themselves  currently  use  a  computer  on  the 
job.  Overall,  39  percent  responded  positively.  Comptrollers  and  safety  department 
heads  represented  the  largest  group  of  computer  users  (30%),  with  supply  department 
heads  the  smallest  (10%).  Use  of  computers  by  department  heads  was  greatly  determined 
by  the  availability  of  computer  hardware  and  software  in  the  department.  People  could 
hardly  be  expected  to  provide  their  own  equipment.  Nonetheless,  there  were  several 
individuals  who  felt  so  strong  a  need  to  computerize  their  work  that  they  employed 
personally  owned  systems. 

Job  Task  Frequency  Ratings 

Department  heads  rated  the  frequency  of  occurrence  of  the  70  tasks  on  a  6-point 
scale  that  ranged  from  "never"  (0)  to  "daily"  (5)  (Appendix  A).  Average  frequency 
ratings  ranged  from  slightly  less  than  4  times  annually  to  almost  daily.  A  listing  of  the 
ratings  of  the  70  tasks  in  terms  of  frequency  can  be  found  in  Table  B-l  of  Appendix  B 
An  overall  mean  task  rating  was  calculated  by  combining  the  ratings  across  the  six 
departments.  From  these  overall  frequency  ratings,  the  following  14  tasks  were  reported 
as  most  frequent  (in  descending  order  of  frequency): 

o  Generating  routine  correspondence; 
o  Scheduling  own  daily  activities; 
o  Monitoring  progress  of  department  tasks; 
o  Generating  non-routine  correspondence; 
o  Coordinating  responsibilities  with  other  department  heads; 
o  Setting  department  work  priorities; 

o  Determining  the  impact  of  other  departments'  activities  on  one’s  own 
department; 

o  Coordinating  use  of  department  resources; 

o  Planning  upcoming  events  for  which  the  department  is  responsible; 
o  Tracking  the  morale  of  department  personnel; 
o  Generating  possible  solutions  for  facilities  or  equipment  problems; 
o  Assessing  the  workload  of  department  personnel; 
o  Generating  possible  assignments  of  personnel  to  match  workload;  and 
o  Assessing  overall  productivity  of  the  department. 

These  tasks  were  all  rated  as  being  performed  at  least  monthly.  Tasks  1-9  and  14  were 
all  from  a  subset  designated  a  priori  as  "operations  management." 
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Frequency  Ratings  by  Department 


Generating  routine  correspondence  (Task  39),  which  was  the  most  frequent 
overall  task,  was  rated  highest  in  frequency  by  heads  of  five  of  the  six  departments  (see 
Appendix  B).  However,  most  of  the  remaining  69  tasks  were  less  consistently  rank- 
ordered  across  departments.  A  nonparametric  statistical  test  (Kendall's  Tau)  was 
calculated  to  compare  the  rank  orderings  of  task  ratings  across  the  six  departments.  This 
test  shows  a  measure  of  agreement  between  the  rankings  by  different  groups.  These 
results  are  presented  in  Appendix  C.  The  similarity  between  departments  in  the  rank 
orderings  of  the  70  tasks  was  compared.  All  of  the  comparisons  were  statistically 
significant. 


When  comparisons  were  made  to  determine  which  department’s  ranking  was  most 
representative  of  all  the  departments  taken  as  a  whole,  it  was  found  that  the  supply 
department  rankings  had  the  most  overlap  with  the  other  departments.  Of  the  14  tasks 
cited  as  most  frequent  (overall),  supply  department  heads  included  13  in  their  top  14. 
The  other  departments  heads  cited  fewer  tasks  that  overlapped:  12  of  the  14  tasks  for 
administration  officers,  11  of  the  14  tasks  for  safety  and  security  officers,  9  of  the  14 
tasks  for  civil  engineers,  and  8  of  the  14  tasks  for  comptrollers.  In  looking  at  the 
similarity  of  task  frequencies,  it  appears  that  a  core  group  of  tasks  occurs  across 
departments. 


Frequency  Ratings  by  Command  Type 


The  16  commands  at  which  interviews  were  conducted  were  grouped  into  three 
categories:  air  stations,  naval  stations,  and  others  (including  amphibious  bases, 
communication  stations,  medical  commands,  training  centers,  and  submarine  bases). 
Statistical  tests  comparing  the  rankings  of  tasks  across  the  three  command  types  revealed 
that  a  very  high  degree  of  agreement  exists  (Appendix  C).  From  this  finding  it  is  clear 
that  department  heads  at  the  various  commands  surveyed  are  similar  in  terms  of  the 
frequency  of  task  requirements  they  encounter. 


Frequency  Ratings  by  Problem  Solving  Level 


The  70  tasks  were  broken  down  into  subsets  according  to  stages  in  a  general 
problem  solving/decision  making  model,  namely,  (1)  identifying  problems  and  causes, 
(2)  generating  action  alternatives  to  solve  the  problem,  (3)  evaluating  these  alternatives, 
(4)  planning  changes,  and  (5)  implementation.  The  average  frequency  ratings  for  tasks 
at  each  problem  solving  level  show  minimal  differences.  In  general,  "generating 
alternatives"  is  the  most  frequent  activity  in  all  departments,  with  the  exception  of  the 
safety  department,  where  "implementation"  is  most  frequent.  "Evaluating  alternatives" 
occurs  least  frequently  in  all  departments. 
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Job  Task  Importance  Ratings 

Department  heads  rated  the  importance  of  the  70  tasks  on  a  5-point  scale  from 
"not  important"  (0)  to  "highly  important"  (4)  (Appendix  A).  Average  importance  ratings 
ranged  from  "slightly  important"  to  just  under  "highly  important"  (Table  B-2  in 
Appendix  B).  Again,  ratings  in  the  six  departments  were  combined  and  averaged  to 
produce  overall  importance  ratings  for  the  70  tasks.  The  14  most  important  tasks,  in 
descending  order,  were: 

o  Coordinating  responsibilities  with  other  department  heads; 
o  Determining  adequacy  of  department  resources; 
o  Setting  department  performance  goals; 
o  Monitoring  progress  of  department  tasks; 

o  Determining  the  impact  of  other  departments’  activities  on  one’s  own 
department; 

o  Setting  department  work  priorities; 

o  Generating  possible  solutions  for  facilities  or  equipment  problems; 
o  Scheduling  own  daily  activities; 
o  Assessing  overall  productivity  of  the  department; 
o  Planning  upcoming  events  for  which  the  department  is  responsible; 
o  Prioritizing  department  activities  for  the  year; 
o  Tracking  the  morale  of  department  personnel; 
o  Preparing  appraisal  forms  for  subordinates;  and 
o  Developing  proposed  annual  budgets. 

Review  of  these  tasks  shows  10  of  the  14  tasks  to  be  from  the  operations 
management  domain.  This  is  a  disproportionately  large  number,  indicating  that 
managers  view  operations  management  tasks  as  relatively  more  important  than  facilities, 
personnel,  and  financial  management  tasks.  Facilities  management  tasks  were  distributed 
widely  over  the  entire  range.  Nearly  half  of  the  personnel  management  tasks  were  rated 
in  the  bottom  14  of  importance  ratings. 

Importance  Ratings  by  Department 

Importance  ratings  of  tasks  were  more  variable  among  departments  than  their 
frequency  ratings.  Of  the  14  most  important  tasks  overall,  comptrollers  rated  only  4  of 
the  above  tasks  in  their  top  14.  Civil  engineers,  safety,  and  security  department  heads 
had  8  of  the  above  tasks  in  their  top  14.  Supply  department  heads  had  9  and 
administration  department  heads  had  10  (Appendix  B).  Those  tasks  rated  as  more 
important  by  a  specific  department  compared  with  the  overall  ratings  tended  to 
emphasize  issues  relevant  to  the  charter  of  that  department.  For  example,  4  tasks 
administration  department  heads  included  in  their  14  most  important  tasks  but  not  found 
in  the  overall  top  14  related  to  personnel  (requirements  and  workload  determination, 
selection,  and  personnel  security  policy).  Similarly,  5  of  the  6  tasks  rated  as  more 
important  by  civil  engineers  but  not  in  the  overall  top  14  had  to  do  with  facilities  and 
equipment  (status  assessment,  projecting  requirements,  planning  and  scheduling 
upgrades). 

A  comparison  of  the  similarity  of  task  importance  rankings  across  the  six 
departments  was  conducted  (Appendix  C).  The  comptrollers'  rankings  were  least  likely 
to  agree  with  other  department  heads’  importance  rankings,  differing  as  they  did  from 
those  of  administration,  safety,  and  security  department  heads.  In  addition, 
administration  department  heads  and  civil  engineers  had  relatively  low  consensus. 
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Important  Ratings  by  Command  Type 

Just  as  was  found  in  the  analysis  of  frequency  ratings,  importance  ratings  of 
tasks  were  found  to  be  similar  across  commands  types.  Nonparametric  comparisons  of 
the  three  base  groups  (air  stations,  naval  stations,  and  others)  showed  the  existence  of 
similar  rank  orderings  for  the  70  tasks  (Appendix  C). 

Importance  Ratings  by  Problem  Solving  Level 

In  general,  all  levels  of  problem  solving  were  rated  as  relatively  equal  in 
importance  by  department  heads.  Across  departments  more  variability  is  apparent.  Civil 
engineers  placed  relatively  high  importance  on  "planning*;  comptrollers  on  "generating 
alternatives"  and  "planning";  administrators  on  "implementing";  security  officers  on 
"planning"  and  "implementing";  and  supply  on  all  phases.  Safety  department  heads 
tended  to  rate  "identifying"  relatively  low,  with  all  other  problem  solving  phases 
consistently  high. 

Combined  Task  Frequency  and  Importance  Ratings 

The  similarity  in  the  rank  ordering  of  the  overall  frequency  ratings  and  overall 
importance  ratings  was  measured  using  Kendall’s  nonparametric  test  (tau  ■  .49;  p  <  .01). 
The  scattergram  for  frequency  plotted  against  importance  (Figure  7)  shows  some 
linearity,  although  high  levels  of  importance  were  assigned  to  tasks  with  a  broad  range 
of  frequencies. 

Six  tasks  were  ranked  in  the  top  10  on  both  frequency  and  importance.  These 

were: 

o  Setting  department  work  priorities; 

o  Planning  upcoming  events  for  which  the  department  is  responsible; 
o  Coordinating  responsibilities  with  other  department  heads; 
o  Determining  the  impact  of  other  departments'  activities  on  one’s  own 
department; 

o  Monitoring  progress  of  department  tasks;  and 
o  Scheduling  own  daily  activities. 

Only  five  more  tasks  achieved  joint  rankings  in  the  top  20  of  both  frequency  and 
importance  ratings.  These  were: 

o  Generating  possible  solutions  for  facilities  or  equipment  problems; 
o  Tracking  the  morale  of  department  personnel; 
o  Assessing  overall  productivity  of  the  department; 
o  Coordinating  the  use  of  department  resources;  and 
o  Preparing  materials  for  briefings. 


Generally,  as  frequency  ranking  declined,  importance  ranking  declined. 

However,  some  tasks  were  rated  relatively  high  in  importance  though  they  had  moderate 
to  low  frequency  rankings.  Examples  were: 

o  Setting  department  performance  goals; 
o  Determining  adequacy  of  department  resources; 
o  Prioritizing  department  activities  for  the  year; 
o  Preparing  appraisal  forms  for  subordinates; 
o  Developing  proposed  annual  budgets;  and 
o  Selecting  prospective  personnel. 

Combined  Ratings  by  Department 

There  was  a  marked  similarity  across  departments  of  the  combined  task 
frequency/importance  ratings.  Nonparametric  measures  of  association  among  the  various 
department  pairs  ranged  from  tau  -  .46  to  .62  (Appendix  C).  All  ratings  of  department 
pairs  attained  statistical  significance  (p  <  .01). 

Department  Heads'  Estimates  of  Hours 

Interviewees  provided  estimates  of  their  annual  time  expenditures  on  20  of  the  70 
tasks  for  which  they  gave  frequency  and  importance  ratings.  The  most  time-consuming 
tasks  in  this  set  (in  descending  order)  were: 

o  Coordinating  use  of  department  resources; 
o  Tracking  repair  of  facilities  and  equipment; 
o  Projecting  facilities/equipment  requirements; 
o  Evaluating  expenditures  compared  to  funding  support; 
o  Preparing  materials  for  briefings; 
o  Preparing  routine  department  status  reports; 

o  Monitoring  department  activity  levels  to  identify  personnel  requirements; 
o  Scheduling  own  daily  activities; 
o  Tracking  resource  requirements;  and 
o  Developing  proposed  annual  budgets. 

Each  of  these  10  tasks  required  an  average  of  an  hour  and  a  half  to  two  and  one 
half  hours  per  week.  Department  heads  commented  that  it  was  very  difficult  to  provide 
accurate  hourly  estimates  for  these  tasks,  but  rough  estimates  were  provided. 

Time  Distribution  Across  Management  Functions 

Department  heads  overall  reported  that  they  spend  the  largest  proportion  of  their 
time  on  planning  (26%).  Other  managerial  functions  demanding  major  portions  of  time 
were  investigating  (19%),  coordinating  (15%),  evaluating  (14%),  and  supervising  (12%). 
The  remaining  14  percent  of  department  heads’  time  is  distributed  fairly  evenly  over 
staffing,  negotiating,  and  representing.  Compared  to  an  earlier  study  of  COs  and  XOs 
(Stuster  et  al.,  1987),  department  heads  spend  much  more  time  planning  and 
investigating,  and  much  less  time  supervising  and  coordinating.  The  COs  stand  out  as 
doing  much  more  representing  and  much  less  investigating  than  either  XOs  or 
department  heads.  These  results  are  presented  in  Figure  8. 
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Attitudes  Towards  Computer  Support 

Almost  all  department  heads  felt  that  computerization  would  improve  the 
performance  of  their  departments.  Many  expressed  a  desperate  need  for  computer 
hardware  and  software,  and  noted  specific  ways  in  which  it  would  be  put  to  use  to  save 
labor,  overcome  personnel  shortages,  improve  work  quality,  allow  quicker  response  time, 
etc.  However,  the  use  of  computers  was  not  regarded  as  a  simple,  entirely  positive 
proposition.  Department  heads  with  exposure  to  the  implementation  of  other  Navy 
automated  data  processing  systems  pointed  out  shortcomings  in  many  of  these  systems, 
and  they  had  no  reason  to  expect  new  systems  to  be  much  different.  There  were  strong 
feelings  that  system  designers  sought  very  little  participation  from  the  intended  users  in 
the  development  of  new  systems.  There  might  be  a  few  interactions  between  the 
designers  and  the  users  in  the  initial  stages  of  development,  but  system  developers 
tended  to  drop  out  of  contact,  not  appearing  again  until  much  later  with  a  system  that 
had  been  developed  beyond  a  point  that  users  could  help  to  remedy.  The  concept  of 
prototyping  with  the  active  participation  of  users  is  still  not  used  to  its  best  advantage. 

The  majority  of  the  department  heads  had  some  knowledge  of  BASIS.  Most  had 
read  or  heard  about  it.  Some  had  received  hands-on  exposure  to  prototype  BASIS 
modules.  Some  department  heads  had  reviewed  the  functional  descriptions  for  the 
BASIS  modules  and  provided  input  to  the  Navy  Regional  Data  Automation  Command 
(NARDAC)  developers.  Most  of  the  department  heads  were  very  supportive  of  the 
BASIS  development  effort.  Those  expressing  a  less  enthusiastic  view  feared  BASIS 
would  not  integrate  with  other  systems  such  as  COPS,  IDAFMS,  and  BEST,  also 
developed  to  assist  base  and  stations  departments.  They  were  also  concerned  that  BASIS 
would  duplicate  systems  they  had  developed  themselves.  Lastly,  some  department  heads 
expressed  concern  for  the  training  time  needed  to  effectively  use  the  new  system. 

Current  Computer  Capabilities 

The  majority  of  the  department  heads  interviewed  function  with  little  or  no 
computer  automation.  Most  department  information  is  recorded,  maintained,  and 
updated  manually.  The  3x5  card  index  system  was  operating  in  many  departments. 

When  there  is  a  request  for  information,  a  time-consuming  process  of  manually  locating, 
tallying,  and  summarizing  the  information  usually  occurs.  Where  automation  does  exist, 
the  department  usually  has  a  few  Zenith  personal  computers,  an  NBI  system,  WANG 
mainframe  terminals,  or,  in  a  few  exceptional  cases,  Macintosh  computers.  These 
systems  are  used  for  word  processing,  database  management,  or  financial  spreadsheet 
applications.  Automation  with  respect  to  comprehensive  databases  dedicated  to 
departments  is  a  new  idea  at  most  Navy  bases  and  stations. 

One  of  the  most  interesting  phenomena  observed  is  the  grass-roots  efforts  of 
departments  to  obtain  computer  hardware  and  develop  software  to  meet  specific  needs 
within  their  departments.  For  example,  a  safety  department  developed  a  DBASE  III 
program  to  track  personal  injuries;  a  comptroller  department  transfers  data  from 
financial  reports  to  LOTUS  123  to  generate  summaries  for  the  CO;  a  civil  engineering 
department  uses  a  Macintosh  graphics  program  to  generate  and  modify  building  plans. 
Department  heads  demonstrated  ingenuity  in  using  old  equipment  as  well  as  the 
personnel  on  hand  to  develop  useful  systems. 
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Department  Heads'  Computer  Needs 


Even  without  extensive  exposure  to  ADP  systems,  department  heads  readily 
expressed  many  needs  in  terms  of  computer  support.  Several  of  these  needs  applied  to 
all  departments,  such  as  the  need  to: 

o  Respond  to  a  greater  number  of  data  requests; 
o  Respond  faster  to  data  requests; 
o  Create  more  accurate  data; 
o  Create  more  up-to-date  data; 
o  Access  a  larger  number  of  data  fields; 
o  Reduce  hardcopy  reports; 
o  Analyze  patterns; 
o  Discover  discrepancies;  and 
o  Project  events  in  the  future. 

Other  needs  were  specific  to  departments.  These  are  summarized  in  Appendix  D. 

Department  Performance  Indices:  Possible  Evaluation  Criteria  for  MIS/DSS 

Department  Heads  said  that  they  employed  traditional  indicators  to  measure 
performance,  with  some  modifications  or  tailoring  within  the  context  of  specific 
department  services  or  activities.  The  bulk  of  the  indicators  were  related  to  accuracy  of 
department  outputs,  quantity  of  department  output,  timeliness  of  responses  to  other 
commands  and  customers,  speed  and  efficiency  of  department  services,  and  department 
productivity.  More  subjective  measures  included  feedback  from  customers,  response 
from  higher  commands,  and  the  department  head’s  perceptions  of  effectiveness.  See 
Appendix  E  for  a  description  of  indicators  by  department. 
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DISCUSSION 

The  user-oriented  model  of  DSS  development  guided  the  efforts  to  this  point 
quite  well.  This  development  approach  provided  a  framework  within  which  to  structure 
the  DSS  design.  The  task  analysis  and  interview  procedure  allowed  the  designers  to 
become  familiar  with  the  kinds  of  responsibilities  that  face  department  heads  of  Navy 
bases  and  stations  and  gain  an  understanding  of  some  of  the  decisions  they  face.  It 
made  possible  isolation  of  those  tasks  that  department  heads  see  as  critical  in  meeting 
their  job  responsibilities.  The  interview  was  useful  in  gauging  user  interest  in  decision 
support,  critical  to  the  success  of  a  DSS.  During  the  interview  session,  many  department 
heads  discussed  critical  ongoing  tasks  that  would  be  greatly  assisted  by  decision  support. 
In  general,  department  heads  were  very  positive  towards  any  movement  to  provide  them 
with  computer  assistance.  Although  there  is  skepticism  about  whether  the  systems  will 
truly  be  state  of  the  art,  few  would  turn  down  computers  offered  to  them. 

Comparisons  Across  Departments  and  Commands 

Design  of  a  DSS  for  the  top  management  of  bases  and  stations  hinges  on,  among 
other  factors,  the  degree  of  similarity  among  department  heads  in  terms  of  tasks  and 
information  requirements.  One  aspect  of  this  issue  is  the  extent  to  which  department 
heads  do  the  same  things,  regardless  of  their  department  and  functional  requirements. 
This  might  be  understood  as  a  question  of  form.  Another  aspect  is  whether  the  required 
problem  solving  and  decision  making  activities  differ  because  of  the  data  peculiar  to 
each  functional  area.  This  might  be  seen  as  a  question  of  content.  To  the  extent  that 
form  is  similar  across  departments  and  bases,  a  case  could  be  made  for  development  of  a 
DSS  that  provides  generic  tools  usable  by  the  entire  top  management  team,  regardless  of 
functional  area  or  hierarchical  position. 

The  job  task  analysis  allowed  the  developers  to  compare  the  ratings  of  a  set  of 
job  tasks  across  different  department  types  and  command  types.  In  overview,  the  task 
frequency  and  importance  ratings  from  the  department  head  interviews  display  a  high 
degree  of  similarity  across  departments  and  across  commands.  Thus,  it  appears  that 
many  tasks  performed  by  department  heads  occur  with  similar  relative  frequency  in 
different  departments  and  on  different  bases.  Although  there  is  somewhat  more 
variability  in  importance  ratings,  these  also  display  considerable  similarity  across 
departments  and  bases.  It  appears  that  the  Navy  context  shared  by  these  commands  and 
departments  generates  a  common  set  of  requirements.  Tools  to  assist  decisions  affecting 
these  critical  tasks  should  be  applicable  to  all  the  department  heads  interviewed. 

Comparison  with  COs  and  XOs 

The  data  gathered  in  this  study  only  allow  comparison  of  the  department  head 
data  with  the  CO  and  XO  data  (Stuster  et  al.,  1987)  in  regard  to  distribution  of  time 
across  management  functions.  Of  the  three  top  management  groups,  department  heads 
reported  the  highest  proportion  of  time  spent  in  planning  and  in  investigating;  they 
reported  less  time  spent  in  supervising  and  coordinating  than  did  either  XOs  or  COs.  Of 
the  three  groups,  XOs  claimed  the  highest  proportion  of  time  devoted  to  staffing  and 
the  least  to  negotiating  and  representing.  COs  reported  a  more  public  role  (representing) 
than  did  the  others,  as  well  as  a  relatively  large  proportion  of  time  spent  in  supervising 
and  planning.  They  reported  relatively  little  time  spent  in  investigating  (Figure  8). 

In  terms  of  DSS  design,  the  data  may  have  two  implications.  First,  the 
distribution  of  time  across  management  functions  may  be  seen  as  documenting  the 
relative  needs  of  the  various  managers  for  computer  aiding.  A  second  implication  is  that 
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a  DSS  may  assist  managers  in  performing  tasks  in  a  more  expedient  manner,  allowing  the 
redistribution  of  time. 

Department  heads  generally  agreed  that  their  COs  and  XOs  are  interested  in  the 
general  status  of  departmental  activities  and  outcomes.  COs  typically  hold  regular 
meetings  with  all  department  heads,  and  usually  during  these  meetings  all  department 
heads  provide  a  departmental  status  report.  Department  heads  were  often  the  primary 
players  for  identifying  and  resolving  problems  in  their  own  departments.  One  of  the 
most  basic  requirements  for  a  DSS  is  that  it  should  have  the  capacity  to  summarize  data 
so  that  department  heads  can  provide  their  COs  and  XOs  with  general  status 
information.  As  an  example,  one  safety  officer  told  us  he  had  developed  a  chart  format 
for  periodic  reporting  to  the  CO.  He  regularly  updated  the  CO  on  a  standard  set  of 
safety  categories,  and  compared  these  with  the  previous  year  as  a  normative  base  period. 

Desired  System  Capabilities 

Department  heads  mentioned  many  features  they  would  like  in  a  DSS.  This 
section  summarizes  three  system  capabilities  department  heads  requested. 

Electronic  Mail 

There  was  an  overwhelming  request  by  department  heads  for  electronic  mail. 

This  was  requested  by  department  heads  in  alt  six  departments.  It  was  generally  felt  that 
electronic  mail  would  greatly  facilitate  communication,  reduce  the  need  to  "play 
telephone  tag,"  and  provide  a  way  to  use  time  more  efficiently. 

Networking  and  Data  Sharing 

Another  common  request  was  for  networking  or  data  sharing  across  departments 
and  across  databases.  Most  department  heads  felt  that  time,  labor,  and  errors  would  be 
reduced  if  the  information  could  be  shared  and  transferred  electronically.  Department 
heads  said  that  quick  access  to  information  that  is  not  necessarily  generated  by  their 
department  would  greatly  facilitate  their  operations. 

Ad  Hoc  Query  Capability 

All  departments  must  regularly  respond  to  unexpected  situations  and  requests  for 
information.  This  situation  usually  requires  ad  hoc  review  and  tabulation  of  data.  For 
example,  administration  might  be  requested  to  report  the  number  of  Hispanics  on  base; 
security,  the  number  of  DW1  arrests  at  the  front  gate  during  the  month;  supply,  the 
number  of  rejected  requisitions  during  the  past  60  days.  These  requests  usually  require 
a  fast  response  and  are  for  information  not  readily  available  from  standard  reports. 

Thus,  the  department  head  must  turn  his  or  her  attention  to  the  request  by  assigning 
personnel  to  it  and  perhaps  becoming  personally  involved  in  information  search, 
consolidation,  and  reporting.  In  some  departments,  such  requests  take  up  a  considerable 
amount  of  the  department  head's  time.  Comptrollers,  for  example,  have  frequent 
interactions  with  their  commanding  officers  about  managing  the  budget,  and  must 
continually  respond  to  CO  requests  for  details  and  advice. 

The  common  thread  in  such  requests  is  the  department  head’s  need  to  obtain 
unanticipated  information  quickly.  Unfortunately,  there  is  no  simple  solution  to  the 
problem--no  single  application  program  that  will  fill  the  need  for  all  departments. 
However,  there  are  noteworthy  implications  for  software  architecture  and  design  of 
user-machine  interface.  First,  databases  should  be  structured  in  a  way  that  permits  users 
to  access  their  content  systematically;  for  example,  hierarchically  organized,  with  the 


25 


ki:kKij^h 


mssm 


user  able  to  access  data  via  any  of  its  key  dimensions  or  their  combinations.  Second,  the 
user  interface  must  permit  the  user  to  specify  search  criteria  in  a  simple  way.  The 
current  mainstream  of  database  systems  places  too  great  a  requirement  upon  the  user  to 
understand  details  about  the  database  and  its  structure  in  order  to  use  it.  Most 
department  heads  are  not  computer  experts  and  should  not  be  expected  to  enter  search 
specifications  in  the  form  of  command  strings  of  logical  and  relational  operators;  a  more 
intuitive  approach  must  be  used. 

Patterns  of  Information  Use 

Review  of  the  task  analysis  data,  interview  data,  and  sample  reports  and  forms 
submitted  by  department  heads  led  to  the  conclusion  that  there  are  some  basic  patterns 
of  information  use  in  decision  making  to  meet  job  demands.  The  choice  of  pattern  in  a 
particular  situation  may  be  governed  by  either  the  requirements  of  the  decision  or  by 
personal  preference  for  information  handling.  We  have  categorized  these  patterns  of  use 
as  record  keeping,  tracking,  and  sleuthing.  These  patterns  are  similar  across  departments 
and  bases.  Although  not  every  manager  uses  ail  patterns  all  of  the  time,  the  patterns 
suggest  different  decision  support  needs  for  different  types  of  situations  or  problems. 

Record  Keeping 

The  first  pattern  involves  entry,  retrieval,  and  maintenance  of  data  in  a  database 
to  produce  standard  reports,  generate  inventories  and  lists,  or  perform  other  routine 
tasks.  This  pattern  may  be  called  record  keeping.  Much  of  what  is  done  with  data  is 
simple  classification  of  events  or  activities  into  standard  categories.  For  instance, 
income  and  expenditures  can  be  categorized  by  date,  organizational  unit,  and  type;  or 
safety  incidents  can  be  categorized  by  date,  type,  severity,  and  work  area.  When  reports 
are  required,  the  data  can  be  listed  or  summarized  according  to  the  various  categories, 
for  example,  expenditures  greater  than  $1000  by  a  department  in  a  particular  category 
during  some  period,  or  major  accidents  on  the  flight  line  during  a  defined  period. 

Often  record  keeping  use  is  dictated  by  a  reporting  requirement  from  a  higher 
authority,  and  the  benefits  to  the  particular  department  are  indirect.  This  routine 
process  can  be  mechanized  to  automatically  produce  this  kind  of  information  at  both  a 
detailed  and  summary  level.  This  pattern  epitomizes  the  automated  record  keeping  and 
routine  reporting  capabilities  of  modern  computer  systems. 

Many  of  the  requests  from  department  heads  for  future  MIS/DSS  capabilities 
reflected  a  record  keeping  orientation.  These  included  requests  for  capabilities  relating 
to  data  entry,  database  content,  and  report  generation.  With  respect  to  data  entry, 
several  department  heads  requested  improved  data-entry  screens.  Suggested 
improvements  included  greater  fidelity  to  paper  forms,  computer-based  instructions  and 
"help  information"  keyed  to  data-entry  fields,  and  "forced-fit"  data  entry— the 
application  forcing  the  operator  to  enter  all  required  fields  with  appropriate  form  and 
content. 

There  were  several  requests  for  the  computerization  of  records  being  kept 
manually  (e.g.,  security  department  incident  reports,  safety  deficiency  notices).  Many  of 
these  requests  will  be  satisfied  by  BASIS.  There  were  also  requests  for  graphics 
capabilities  not  currently  planned  as  part  of  BASIS.  For  example,  several  public 
works/civil  engineering  departments  wanted  the  ability  to  store  and  retrieve  maps  and 
floorplans.  Comptrollers  and  others  wanted  to  be  able  to  generate  graphs  and  charts 
from  existing  data  files  either  for  their  own  use  or  for  use  in  making  presentations  to 
commanding  officers. 


Department  heads  in  all  departments  cited  specific  reports  they  would  like  but 
were  unable  to  generate  with  current  systems.  For  example,  security  department  heads 
would  like  to  maintain  a  database  of  incident  reports  and  be  able  to  search  the  database 
using  open-ended  search  criteria.  The  same  applies,  with  their  own  databases,  to  heads 
of  other  departments,  for  example,  safety  department  databases  of  accident  reports; 
comptroller  and  civil  engineering/public  works  department  databases  of  financial 
information;  and  administration  department  databases  of  personnel  availability.  What  is 
common  across  departments  is  the  wish  to  define  report  content  and  database  search 
criteria.  In  simple  terms,  departments  want  flexible  record  keeping  systems. 

Tracking 

The  second  pattern  involves  tracking  time -dependent  activities  so  that  what  needs 
to  get  done  gets  done  when  required  and  resources  are  used  efficiently.  Department 
heads  have  a  pressing  requirement  to  keep  track  of  ongoing  events.  They  may  be 
involved  in  developing  plans,  executing  projects,  or  managing  their  budgets.  To 
accomplish  this  tracking  function  they  currently  use  a  wide  variety  of  resources  ranging 
from  paper  and  pencil,  to  clipboard,  to  project  management  programs  on 
microcomputers.  Often  department  heads  rely  heavily  on  their  own  memory  in 
monitoring  the  activities  of  their  departments.  Their  success  probably  varies  widely, 
depending  on  their  abilities,  tools,  and  perseverance. 

This  pattern  is  structured,  but  the  structure  is  usually  imposed  by  the  department 
itself.  Concrete  examples  include  an  administration  department’s  use  of  a  computer- 
based  personnel  log  to  keep  track  of  the  locations  and  rotation  dates  of  TDY  personnel; 
a  priority  list  used  by  a  civil  engineer  to  keep  track  of  building  events;  lists  of 
inspection  discrepancies  and  action  dates  maintained  by  safety  departments.  Such 
tracking  activities  directly  benefit  the  department  in  executing  its  responsibilities  and  are 
not  necessarily  dictated  by  any  external  reporting  requirement. 

Department  heads  described  several  different  types  of  tracking  activities  they 
need  to  perform.  These  differ  among  individuals  and  department  types,  but  they  share  a 
common  premise  and  have  a  similar  goal,  for  example: 

Premise:  An  event  must  occur  at  a  particular  time. 

Goal:  Assure  that  the  event  occurs. 

The  premise  and  goal  are  often  influenced  by  "properties"  associated  with  the 
event,  that  is,  its  type,  priority,  who  is  responsible  for  it,  and  so  forth.  When  it 
becomes  clear  that  circumstances  do  not  permit  all  goals  to  be  met,  these  other  properties 
can  be  taken  into  account  to  ensure  that  the  most  consequential  events  occur. 

Examples  of  events  that  must  be  monitored  by  different  departments  include: 

Administration  Status  of  correspondence; 

Comptroller  Status  of  accounts  payable; 

Civil  Engineering/ 

Public  Works  Status  of  work  in  progress; 

Safety  Status  of  required  periodic  physical  exams; 

Security  Status  of  AWOL  personnel  cases; 

Supply  Status  of  requisitions. 


Though  the  events  themselves  differ,  the  manner  in  which  they  are  monitored  is 
usually  quite  similar.  A  time-ordered  list  of  events  is  created.  The  manager  checks  the 
list  periodically  to  ensure  that  events  occur.  As  time  passes,  completed  events  are 
crossed  off  the  list  or  status  changes  are  noted  and  new  events  are  added.  Those 
overdue  are  given  appropriate  attention  to  get  them  back  on  schedule  or  otherwise 
dispensed  with. 

Department  heads  use  many  different  tools  to  manage  events.  Though  content 
and  form  differ,  the  underlying  structure  is  most  often  a  list.  Individuals  reported  that 
on  many  occasions,  however,  a  simple  list  was  not  dynamic  enough  to  accommodate  last 
minute  changes  or  delays  in  scheduling.  The  interrelationships  and  dependencies  of 
items  on  the  list  unfortunately  too  often  resided  within  the  memory  of  the  individual  in 
charge.  These  individuals  are  too  often  subject  to  the  common  problems  of  forgetting  or 
confusion.  The  formal  procedures  for  Gantt  and  PERT  charting  are  too  labor-intensive 
to  be  practical  if  done  manually.  It  appears  that  many  managers  would  be  aided  by  an 
interactive,  computer-based  list  management  program  that  would  permit  the  user  to  do 
the  following: 

1.  Enter  tasks  or  modify  tasks; 

2.  Assign  task  or  event  properties  (e.g.,  task  type,  priority,  status,  due  date, 
responsible  individual); 

3.  Sort  the  list  by  time  or  event  properties;  and 

4.  Filter  the  list  to  extract  events  meeting  certain  open-ended  criteria 

(e.g.,  events  of  specified  type  and  priority  that  are  due  during  a  particular 
time  interval); 

5.  Create  a  graphic  display  or  other  easily  grasped  summary  of  current  status 
at  any  time. 

No  software  with  all  of  these  features  is  presently  available,  although 
computerized  calendars,  datebooks,  and  the  like  have  some  of  the  required  features. 
Although  the  list  is  probably  the  simplest  and  most  universal  tool  used  by  a  manager, 
more  sophisticated  or  specialized  tools,  such  as  project  management  software,  would  be 
useful.  Bearing  in  mind  the  commonalities  of  these  tracking  requirements,  system 
designers  should  develop  a  system  for  meeting  department  heads’  tracking  requirements. 

Sleuthing 

The  third  pattern,  which  we  shall  call  sleuthing,  involves  examination  of  the 
contents  of  a  database  to  find  the  answer  to  a  non- routine,  atypical  question.  It  may 
also  involve  manipulation  of  data  in  the  database  in  an  analytic  or  evaluative  approach. 
This  pattern  is  less  structured  and  less  governed  by  external  requirements  than  the  two 
previous  patterns.  Concrete  examples  are  multi-level  analyses  performed  on  financial 
databases  to  determine  areas  of  over-  or  underspending,  inappropriate  budget  allocation, 
or  other  discrepancies.  Or  data  from  one  time  period  must  be  compared  with  another, 
with  the  user  looking  at  historical  trends  as  a  basis  for  projecting  into  the  future.  This 
pattern  is  common  in  comptroller  and  civil  engineering  departments  and,  to  a  lesser 
degree,  in  supply.  In  general,  the  analyses  performed  benefit  the  department  directly 
and  are  not  usually  dictated  by  an  external  reporting  requirement. 
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To  facilitate  sleuthing,  department  heads  requested  capabilities  to  conduct  several 
different  types  of  analyses.  Though  these  analyses  differ  by  individual  and  department 
type,  they  have  a  common  premise  and  intend  to  answer  an  often  unstated,  but 
underlying,  question: 

Premise  (P):  A  problem  may  exist. 

Question  (Q):  Does  it  and,  if  so,  what  is  its  source? 

Examples  of  premises  and  questions  are: 

Administration 

(P)  Personnel  are  needed  to  accomplish  a  task. 

(Q)  Are  personnel  with  the  required  skills  available? 

Civil  Engineering/Public  Works 

(P)  The  rainy  season  is  approaching  and  the  roof  of  building  304  needs 

replacement, 

(Q)  Is  the  roofing  job  on  schedule? 

Comptroller 

(P)  The  base  is  overspent  on  utilities. 

(Q)  Who  is  responsible  and  how  may  future  costs  be  reduced? 

Safety 

(P)  The  base  needs  to  reduce  exposure  to  asbestos. 

(Q)  Where  on  base  are  asbestos  hazards  located  and  how  are  plans  progressing  to 
eliminate  them? 

Security 

(P)  The  threat  of  terrorist  attack  has  increased  in  recent  weeks. 

(Q)  What  are  weak  points  in  the  base’s  security  perimeter,  and  how  may  they  be 
strengthened? 

Supply 

(P)  A  maintenance  manager  contends  that  requisitions  are  taking  significantly 

longer  to  process  than  in  the  past. 

(Q)  Is  the  contention  correct  and,  if  so,  what  is  the  most  likely  reason? 

Although  the  foregoing  premise-question  pairs  are  quite  different,  a  department 
head  attempting  to  deal  with  any  pair  is  likely  to  go  through  a  similar  process.  The 
steps  in  this  process  involve  problem  recognition  and  definition,  generating  and 
evaluating  solutions  to  resolve  the  problem,  and  implementing  solutions.  Nothing  can 
happen  if  the  department  head  does  not  recognize  the  problem.  Doing  so  requires 
experience  and  an  indicator  to  alert  the  department  head.  Given  these,  the  department 
head  will  typically  focus  on  data  to  locate  the  problem  source.  For  example,  a 
comptroller  attempting  to  learn  why  utilities  are  overspent  will  look  at  actual  versus 
budgeted  spending  by  department,  compare  current  and  past  expenditures,  and  examine 
other  financial  indicators.  This  process  is  facilitated  when  the  system  (1)  provides  high- 
level  indicators  to  flag  potential  problems  and  (2)  is  structured  so  that  the  user  can  focus 
on  the  database  at  successively  finer  levels  of  detail. 


Another  aspect  of  analyses  performed  by  department  heads  concerns  the 
predictability  of  problems  before  they  occur,  that  is,  predictive  analyses.  As  in  the 
analysis  of  existing  problems,  problem  prediction  is  based  on  a  premise  and  is  intended 
to  answer  an  underlying  question: 

Premise:  A  problem  may  exist  in  the  future. 

Question:  Where  will  the  problem  occur  and  what  will  cause  it? 

Predicting  problems  is  more  difficult  than  detecting  existing  ones  for  several 
reasons.  The  department  head  must  possess  a  reasonable  model  of  the  system  in  which 
problems  may  occur.  S/he  must  be  provided  with  leading  indicators”  of  potential 
problems.  Then  s/he  must  be  able  to  interpret  the  indicators  accurately.  More 
fundamentally,  a  department  head  must  have  the  proper  mind  set  to  think  in  terms  of 
future  events  rather  than  simply  reacting  to  present  events.  Several  of  the  department 
heads  we  interviewed  did  attempt  to  make  such  predictions.  Typically,  these  were 
managers  who  were  computer-sophisticated.  They  usually  were  found  in  civil 
engineering,  comptroller,  and  administration  departments,  although  they  could  also  be 
found  in  other  departments.  Most  felt  that  they  could  be  more  effective  if  they  had 
better  predictive  tools  and  more  up-to-date  information.  Lack  of  adequate  tools  or 
accurate  and  timely  information  precludes  developing  useful  predictive  power. 

While  several  of  the  department  heads  we  interviewed  attempted  to  anticipate 
problems,  the  majority  did  not--at  least  not  in  any  formal  way.  For  example,  security 
departments  gathered  and  submitted  incident  reports  to  higher  levels,  but  did  not  always 
develop  in-house  statistics  for  predicting  future  incidents.  Similar  attitudes  were  evident 
in  other  departments.  Most  of  the  department  heads  we  interviewed  tended  to  take  a 
reactive  rather  than  a  proactive  stance  toward  problems.  This  may  well  be  due  to  the 
lack  of  computer  support  and  accurate,  timely  information  that  would  allow  them  to  take 
a  more  analytical,  evaluative  approach  to  management  of  their  departments. 

Many  department  heads  requested  a  *what-if"  capability  in  new  systems.  They 
want  to  be  able  to  manipulate  variables  in  a  situation  and  calculate  results  under 
different  conditions,  as  in  spreadsheet  programs.  The  question  being  asked  in  this  case 
is,  "If  1  provide  these  inputs,  what  will  be  the  result?"  The  "what-iP  question  can  also 
be  framed  to  predict  a  result  in  terms  of  time  (e.g.,  "If  things  continue  as  they  have  in 
the  past,  what  will  be  the  result  four  weeks  from  now?"). 

Thus,  the  "what-if"  capability  is  a  generalized  way  to  make  or  test  predictions. 
The  "what-if"  capability  is  also  a  feature  of  project  management  programs  that  predict 
the  effects  of  personnel  and  physical  resource  allocations  upon  project  costs  and 
scheduling  in  graphic  (e.g.,  Gantt  or  PERT  charts)  and  tabular  form.  Few  department 
heads  use  project  management  software.  It  is  expensive,  more  difficult  to  use  than  a 
spreadsheet,  and  has  less  general  applicability.  However,  such  software  would  be  very 
helpful  to  department  heads  who  manage  complex  projects. 

The  three  patterns  of  record  keeping,  tracking,  and  sleuthing  are 
oversimplifications,  but  they  provide  a  useful  framework  for  structuring  thought  about 
how  department  heads  typically  use  information  and  computer  support  to  meet  job 
responsibilities.  Our  survey  suggests  that  the  traditional  orientation  of  a  department  in 
using  a  computer  may  influence  department  head  perceptions  of  computer  use.  For 
example,  where  record  keeping  prevails  (as  it  does  in  safety,  security,  and  supply 
departments),  the  computer  is  regarded  not  as  an  analytical  tool  but  as  a  record-keeping 
tool.  In  departments  where  tracking  is  evident  (as  it  is  in  administration,  comptroller, 
and  civil  engineering/public  works  departments),  there  is  a  strong  computer  orientation 
and  often  an  expressed  need  for  additional  computerization.  Tracking  and  sleuthing 
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often  overlap,  and  where  they  are  common  (in  comptroller  and  civil  engineering/public 
works  departments),  department  heads  make  more  effective  use  of  computers  as 
analytical  and  management  tools.  These  departments  have  generally  also  had  a  longer 
history  of  computer  use  than  those  characterized  by  a  record-keeping  orientation,  and 
therefore  their  department  heads  generally  have  greater  computer  sophistication. 

Many  of  the  heads  of  these  departments  did  not  take  a  historic.il  view  of  the 
computer  records  their  departments  generate;  the  attitude  seemed  to  be  that  reports  were 
generated  because  they  were  required  by  higher  command.  There  were  exceptions, 
however;  for  example,  a  security  department  head  who  used  records  of  past  incident 
reports  to  identify  patterns  for  the  purpose  of  allocating  department  resources.  By 
providing  department  heads  with  computer  tools  of  an  analytic  nature,  these  data  may  be 
used  by  them  to  identify  and  possibly  predict  problems,  analyze  solutions,  and  evaluate 
implementations. 

MIS/DSS  Evaluation 

Automated  systems  designed  to  be  used  by  managers  are  tools  intended  to 
increase  managerial  productivity  in  both  qualitative  and  quantitative  terms.  Criteria  for 
evaluating  the  impact  of  the  implementation  and  use  of  such  systems  are  the  same 
performance  measures  traditionally  used  to  assess  department  productivity.  Although  a 
lengthy  discussion  of  the  evaluation  process  is  not  the  focus  here,  an  effort  was  made  to 
generate  a  group  of  department  performance  indicators  for  the  six  functional  areas 
examined.  It  is  recommended  that  these  indicators  be  adapted  to  measure  the  effect  of 
DSS  implementation  on  department  productivity. 

A  l  'tew  of  the  User 

It  is  fitting  that  we  end  this  section  with  a  brief  description  of  how  the  user  and 
the  user's  decision  processes  may  be  effectively  visualized  in  the  design  of  a  DSS. 

First,  the  user  is  not  interested  in  the  hardware,  software,  system  architecture,  or 
the  operating  system  involved  in  an  information  system.  The  terminal  or  workstation  is 
nothing  more  than  a  conduit  through  which  the  user  hopes  to  be  able  to  acquire  or  store 
desired  information.  The  user  appreciates  a  dialogue  with  the  system  that  uses  the 
vocabulary  to  which  s/he  is  already  accustomed.  The  user  expects  that  the  system,  at  a 
minimum,  will  automate  the  most  routine  operations  performed  on  the  job.  It  is 
permissible  for  data  entry  to  require  as  much  effort  as  manual  procedures  as  long  as  the 
user  perceives  that  retrieval,  modification,  and  summary  reports  are  greatly  facilitated  by 
the  system. 


Although  it  is  often  necessary  to  maintain  two  separate  processes  or  systems  (the 
old  and  the  new)  when  initially  implementing  a  system,  it  is  important  that  the  old 
system  be  eliminated  as  quickly  as  possible.  Our  studies  disclose  that  users  fear  that 
they  will  have  to  maintain  redundant  information.  For  this  reason  alone,  the  design  of  a 
new  system  should  provide  for  use  of  existing  information  whenever  possible.  This 
implies  that  the  data  element  glossary  of  definitions  be  maintained  rigorously  to  avoid 
needless  redundancies  as  the  system  evolves.  There  are  permissible  exceptions  when 
certain  data  elements  are  known  to  be  error-prone  or  susceptible  to  change  and  require 
occasional  verification. 

Users  expect  a  system  to  be  useful  immediately.  They  are  not  impressed  with 
the  technology--just  the  immediate  results.  So  it  is  important  in  building  a  system  that 
the  developer  address  some  straightforward  tasks  that  are  not  currently  handled  well, 
making  it  easy  for  the  user  to  employ  the  system  to  do  these  things.  And,  as  in  this 
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study,  the  developer  must  work  closely  with  the  potential  user  to  determine  what  tasks 
are  the  best  candidates  for  improvement  through  computerization. 


In  working  with  users  during  the  development  process,  the  developer  must  first 
seek  to  understand  the  range  of  tasks  that  the  user  performs  in  the  course  of  performing 
the  job.  It  is  the  responsibility  of  the  system  designer  to  convey  to  the  user  what  part 
of  that  range  can  realistically  be  addressed  by  the  system  under  consideration.  We  have 
found  that  users  are  not  only  helpful,  but  eager  to  assist  in  refining  concepts  and  ideas 
into  executable  objectives.  Here  is  where  the  technique  of  sequential  prototyping  is 
especially  useful.  Starting  with  a  "storyboard”  to  show  how  the  system  might  be  used  to 
accomplish  a  specific  class  of  tasks  or  decisions,  the  developer  can  move  iteratively 
toward  a  working  prototype,  using  comments  and  critiques  from  the  intended  user.  The 
user,  at  the  same  time,  develops  an  understanding  of  the  designer’s  efforts  and 
constraints.  This  type  of  interaction  and  participation  satisfies  the  user’s  needs  and 
demands  to  be  heard,  fostering  feelings  of  ownership,  while  providing  the  developer 
with  needed  information  that  goes  a  long  way  toward  producing  a  successful  system. 


We  have  found  that  obtaining  samples  of  summary  notes  and  charts  is  a  most 
enlightening  technique  for  gaining  information  and  ideas  about  the  decision  making 
process.  These  materials,  which  they  have  developed  to  help  themselves,  provide 
revealing  insights  into  the  mental  processes  individuals  use.  It  is  not  likely  that  an 
individual  will  systematically  gather  and  summarize  information  unless  it  is  relevant  to 
her/his  decision  process.  Summaries  and  charts  reveal  how  the  individual  prefers  to  see 
information  displayed.  If  the  rationales  behind  these  summaries  or  charts  are  not 
obvious,  the  system  developer  should  query  the  user  for  explanation.  Additionally, 
summaries  and  charts  provide  ideas  as  to  how  information  might  be  combined  and  used 
to  estimate  parameters  along  some  decision  dimension.  In  a  more  rigorous  study, 
manipulation  of  parameter  values  in  simulations  will  allow  for  the  analysis  of  the  effects 
of  these  changes  on  decision  outcomes. 


It  is  important  for  the  designer  to  appreciate  the  fact  that  the  user  is  a  limited 
capacity  processor.  Each  cognitive  demand  consumes  part  of  that  capacity.  The  less  the 
user  is  occupied  with  the  operation  of  the  MIS  or  DSS,  the  more  capacity  can  be  devoted 
to  performance  of  the  task  at  hand.  Graphics  and  other  technologies  such  as  voice 
recognition  and  speech  generation  are  areas  in  which  much  work  is  ongoing  to  facilitate 
the  user-computer  dialogue.  We  have  incorporated  some  of  these  concepts  within 
proposed  prototypes  such  as  the  SMART  MAP  system  discussed  in  Stuster  el  al.  (1987). 
However,  much  can  be  done  in  system  design  even  without  using  higher  technologies. 

For  example,  systems  that  provide  the  user  with  feedback  concerning  the  status  of 
computer  operations  is  extremely  beneficial.  Systems  without  such  feedback  can  cause 
the  user  to  wonder  whether  the  system  is  working  as  it  should.  This  uncertainty  can  be 
uncomfortable  and  disconcerting,  especially  during  long  computer  operations. 


Lastly,  the  system  developer  must  be  prepared  to  listen  to  the  user’s  requests.  If 
the  developer's  job  is  done  properly,  the  user  will  be  making  such  requests  based  on 
knowledge  of  the  anticipated  scope  of  the  project.  But  even  if  it  doesn’t  seem  to  be 
within  the  project’s  scope,  one  should  not  overlook  the  Golden  Rule  of  salesmanship, 
"The  customer  is  always  right."  Whether  or  not  this  is  true  is  besides  the  point.  Both 
the  user  and  the  designer  are  better  served  by  assuming  that  it  is. 
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CONCLUSIONS 


1.  The  user-oriented  model  of  DSS  development  described  in  this  report  provides  a 
useful  framework  for  developing  a  DSS  for  top  management  at  Navy  bases  and  stations. 
It  emphasizes  the  involvement  of  the  user  at  all  stages  of  development,  from  needs 
analysis  to  implementation  and  revision.  The  DSS  development  model  ensures  the 
product  is  user-defined,  user-specified,  and  user-evaluated. 

2.  Department  heads  of  Navy  bases  and  stations  comprise  a  reasonably  homogeneous 
group  of  target  users,  who  could  benefit  greatly  from  a  DSS  that  provides  generic  tools 
usable  across  a  wide  range  of  managerial  problems  for  data  display,  manipulation,  and 
analysis. 

3.  Department  heads  are  anxious  to  receive  computer  and  decision  support  capabilities. 
They  believe  these  capabilities  will  substantially  improve  their  efficiency  and 
effectiveness  in  meeting  their  departmental  responsibilities. 

4.  Three  patterns  of  information  use  were  common  among  department  heads:  record 
keeping,  tracking,  and  sleuthing.  These  patterns  have  implications  for  DSS  tools  and 
data  retrieval  methods. 

5.  The  DSS  should  have  as  one  of  its  goals  integration  with  existing  systems,  rather  than 
proliferation  of  competing  systems  that  cannot  exchange  information. 
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DEPARTMENT  HEAD  TASK  ANALYSIS  AND  INTERVIEW 


DEMOGRAPHIC  DATA 

Department  sire  (total  billets  presently  filled):  _ Military  _ Civilian 

Number  of  people  you  directly  supervise:  _ 

Average  base  population:  _ 

Your  rank/grade:  _ 

Months/years  in  your  department  head  job:  _ months  _ years 

Rate  your  experience  as  a  user  of  computer  programs  and  applications  on  a  scale  from  0  to  4, 
where  0  means  "inexperienced"  and  4  means  "very  experienced."  For  example,  a  person  who  has 
never  used  any  computer  programs  would  rate  his/her  experience  as  0;  a  person  who  has  used 
several  different  programs  extensively  on  several  different  computers  would  rate  his/her 
experience  as  4. 

Your  answer:  _ 

Which  of  the  following  computer  programs  have  you  personally  used?  (0-no;  1-yes) 

_  Word  processing 

_  Electronic  spreadsheet 

_  Database 

_  Communications 

Do  you  yourself  currently  use  a  computer  on  the  job?  (0-no;  1-yes)  _ 

FREQUENCY  AND  IMPORTANCE  OF  MANAGEMENT  TASKS 


Response  Scales 


Frequency  Scale 


0 

1 _ 

1 

2 

3 

4 

5 

1 

1 

Never 

Less  than 

Quarterly/ 

Monthly 

Weekly 

1 

Daily 

4  times 

Bimonthly 

(1-2  times 

(1-3  times 

(5+  times 

per  year 

(4-10  times 

per  month) 

per  week) 

per  week) 

per  year) 


Importance  Scale 

0  12  3  4 


Not  Moderately  Highly 

Important  Important  Important 
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Task  Statements 


Facilities  Management 

1.  Project  near-  and  long-term  facilities/equipment  requirements? 

2.  Pian  improvement  or  upgrade  of  facilities/equipment? 

3.  Formulate  security  improvements  for  facilities/equipment? 

4.  Assess  operational  status  of  facilities/equipment? 

5.  Check  to  determine  any  upcoming  events  that  require  facilities/equipment  from  your 
department? 

6.  Schedule  use  of  facilities/equipment? 

7.  Monitor  use  of  department  facilities/equipment? 

8.  Generate  possible  solutions  for  facilities/equipment  problems? 

9.  Track  repair  of  facilities/equipment? 

10.  Evaluate  scheduling  of  facilities  maintenance  and/or  construction  to  minimize  disruption  to 
personnel? 

Personnel  Management 

1 1 .  Monitor  current  and  anticipated  levels  of  department  activity  to  identify  near-  and  long¬ 
term  personnel  requirements? 

12.  Set  recruiting  priorities  to  fill  position  openings? 

13.  Select  prospective  personnel  for  openings  in  your  department? 

14.  Assess  workload  of  department  personnel? 

15.  Generate  possible  assignments  of  personnel  to  match  workload? 

16.  Prepare  appraisal  forms  for  your  subordinates? 

17.  Review  results  of  advancement  exam  to  assess  group  pass  rates? 

18.  Identify  appropriate  Navy  standards  regarding  disciplinary  cases? 

19.  Track  number  of  security  cases,  mast  cases,  and  other  disciplinary  actions  over  time? 

20.  Project  the  training  needs  of  your  department? 

21.  Monitor  levels  of  training  for  personnel? 

22.  Track  personnel  retention  rates  for  department  personnel? 

23.  Track  "types  of  separations"  for  department  personnel? 

24.  Track  the  general  morale  of  department  personnel? 

25.  Compare  occupational  injury  and  illness  rates  to  previous  rates  and  Navy  goal? 

26.  Recommend  changes  in  personnel  policy  related  to  security? 

27.  Validate  requests  for  information  pertaining  to  department  personnel? 

Operations  Management 

28.  Prioritize  department  activities  for  the  fiscal  year? 

29.  Track  resource  requirements  for  department  tasks? 

30.  Assess  overall  productivity  of  your  department? 

31.  Set  performance  goals  for  your  department? 

32.  Determine  if  existing  resources  are  adequate  for  fulfilling  your  department’s  mission? 

33.  Develop  revised  policies  and  procedures  for  tasks  in  your  department? 

A  -  2 


1 

$| 

J 


Operations  Management  (continued) 

34.  Set  priorities  for  the  work  activities  of  your  department? 

35.  Coordinate  use  of  department  resources? 

36.  Plan  activities  for  which  your  department  is  responsible  in  anticipation  of  upcoming  events? 

37.  Coordinate  areas  of  responsibility  with  other  department  heads? 

38.  Determine  the  impact  of  activities  of  other  departments  on  accomplishing  the  mission  of 
your  department? 

39.  Generate  routine  correspondence  relating  to  the  activities  of  your  department? 

40.  Generate  non-routine  correspondence  relating  to  the  activities  of  your  department? 

41.  Prepare  routine  department  status  reports? 

42.  Prepare  non-routine  reports  concerning  department  operations? 

43.  Complete  standard  forms  related  to  travel,  training,  etc.? 

44.  Prepare  materials  for  briefings? 

45.  Monitor  progress  on  tasks  performed  by  your  department? 

46.  Monitor  compliance  with  standard  operating  procedures  for  crisis  situations? 

47.  Schedule  daily  work  activities  in  which  you  are  involved? 

48.  Modify  department  activities  based  on  use  rates? 

49.  Assess  processing  times  for  products/services  compared  to  goals? 

50.  Track  scheduling  and  progress  of  major  preventive  and  corrective  maintenance  activities? 

51.  Assess  status  of  safety  program? 

52.  Initiate  corrective  actions  to  resolve  safety  problems? 

53.  Evaluate  the  technical  aspects  of  proposed  contracts? 

54.  Carry  out  public  relations  responsibilities  and  activities? 

55.  Assess  the  impact  of  proposed  actions  of  your  department  on  the  local  community? 

56.  Reschedule  activities  to  adjust  for  actual  vs.  available/projected  manhour  expenditures? 

Financial  Management 

57.  Develop  proposed  annual  department  budget  and  cost  allocations? 

58.  Assess  optimal  budget  allocations? 

59.  Provide  feedback  to  individual  section  heads  concerning  their  proposed  budgets? 

60.  Evaluate  expenditures  compared  to  funding  support? 

61.  Monitor  expenditures  of  individual  sections  or  departments? 

62.  Monitor  expenditures  in  terms  of  regulations  and  legal  implications? 

63.  Generate  alternatives  for  absorbing  budget  cuts? 

64.  Revise  the  working  budget  for  your  department? 

65.  Redirect  funds  among  activities  of  your  department? 

66.  Identify  financial  irregularities  in  expenditures? 

67.  Review  expenses,  sales  and  profits  of  organizational  units  operated  with  nonappropriated 
funds? 

68.  Project  capital  investment  needs? 

69.  Develop  cost-cutting  programs  or  action  items? 

70.  Evaluate  effectiveness  of  cost-cutting  programs? 
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RESOURCE  REQUIREMENTS  OF  MANAGEMENT  TASKS 


Labor  Hours  Question 


How  many  hours  do  you  personally  spend  on  an  annual  basis  to  .  .  . 


Task  Statements 

I.  Project  near-  and  long-term  facilities/equipment  requirements? 

5.  Check  to  determine  any  upcoming  events  that  require  facilities/equipment  from  your 
department? 

6.  Schedule  use  of  facilities/equipment? 

7.  Monitor  use  of  department  facilities/equipment? 

9.  Track  repair  of  facilities/equipment? 

II.  Monitor  current  and  anticipated  levels  of  department  activity  to  identify  near-  and  long-term 
personnel  requirements? 

16.  Prepare  appraisal  forms  for  your  subordinates? 

19.  Track  number  of  security  cases,  mast  cases,  and  other  disciplinary  actions  over  time? 

20.  Project  the  training  needs  of  your  department? 

22.  Track  personnel  retention  rates  for  department  personnel? 

29.  Track  resource  requirements  for  department  tasks? 

35.  Coordinate  use  of  department  resources? 

41.  Prepare  routine  department  status  reports? 

44.  Prepare  materials  for  briefings? 

47.  Schedule  daily  work  activities  in  which  you  are  involved? 

57.  Develop  proposed  annual  department  budget  and  cost  allocations? 

58.  Assess  optimal  budget  allocations? 

60.  Evaluate  expenditures  compared  to  funding  support? 

63.  Generate  alternatives  for  absorbing  budget  cuts? 

66.  Identify  f'nancial  irregularities  in  expenditures? 


INTERVIEW  SCHEDULE 


1.  What  measures  do  you  use  to  evaluate  your  department’s  success  in  meeting  its  mission?  How 
can  performance  of  your  department  be  evaluated?  How  do  you  determine  your  department's 
productivity? 

2.  What  are  the  present  computer  capabilities  of  your  department?  What  information  do  you  most 
frequently  request  that  could  be  incorporated  in  a  database?  What  types  of  information  do  you 
regularly  provide  up  the  chain  of  command  or  to  other  departments?  What  types  of  data  could 
you  use  from  other  departments  or  data  bases  if  they  were  easily  accessible?  How  frequently  is 
the  exchange  of  information  with  other  departments  on  base  required? 

3.  What  issues  are  preventing  or  discouraging  you  from  making  greater  use  of  management 
information  systems  that  are  currently  available  on  your  base/station? 

4.  Please  provide  me  with  a  sample  of  the  reports,  figures,  graphs,  and  tables  that  your 
department  produces  for  recordkeeping,  reporting,  or  presentations. 
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Table  B  •  1 


TASK  FREQUENCY  RATINGS 


Administration  Civil  Engineer 


Mean 

SO 

Mean 

SO 

t  .93 

0.96 

4.07 

1.27 

1.80 

1.01 

3.71 

1.44 

1.20 

0.94 

1.93 

1.27 

2.13 

1.68 

3.21 

1.37 

2.53 

1.51 

3.29 

1.07 

3.07 

1.22 

2.43 

1.70 

2.73 

1.33 

2.86 

1.51 

2.07 

1.16 

4.21 

0.97 

1.67 

1.29 

4.29 

1.14 

1.47 

1.36 

3.79 

1.31 

3.00 

1.07 

2.36 

1.28 

2.13 

1.06 

1.86 

1.23 

1.73 

1.10 

1.57 

1.16 

3.20 

1.32 

2.86 

1.29 

2.93 

1.49 

2.86 

1.51 

2.87 

1.06 

1.71 

0.99 

1.33 

0.82 

0.57 

0.65 

1.53 

0.83 

1.14 

1.23 

1.40 

1.40 

0.50 

0.65 

2.40 

0.83 

1  50 

0.52 

2  27 

0.88 

1.36 

0.50 

1.67 

1.23 

0.64 

0.63 

0.87 

0.64 

0  50 

0.52 

4  20 

1.08 

2.86 

1.29 

0  73 

0  46 

1.14 

1.17 

2.07 

1.33 

0  64 

0.84 

2.80 

1.57 

1.14 

1.29 

2.13 

0.74 

2  29 

1.27 

2.13 

1.25 

2  86 

1.17 

3  13 

0.83 

3  00 

0  78 

2.13 

1.13 

1.71 

0.91 

2  60 

1.06 

2.21 

1.12 

2.40 

0  91 

2.07 

0.62 

3.40 

1.35 

3.71 

0.83 

3  07 

1.62 

3  50 

1.45 

3.40 

1.18 

3.07 

1.21 

3  93 

0.80 

3.86 

0  86 

3  47 

1.06 

3.57 

1  34 

4  33 

0.72 

4.14 

1.17 

3.60 

1.12 

3  86 

1.35 

3.13 

1.60 

2.71 

1.44 

2.33 

1.18 

2.50 

1.09 

2.67 

1.45 

2.07 

1.07 

2  33 

1.29 

2.50 

1  09 

3  87 

1.30 

4  36 

0  74 

2.27 

1.33 

2.29 

1.33 

4.00 

0.93 

4.50 

0.94 

2.40 

1.24 

2.71 

1.14 

2.20 

1.37 

2.14 

1.29 

1.20 

1.26 

3.07 

1.59 

2.00 

1.51 

1.64 

0.84 

1.60 

0.83 

2.29 

0.99 

0.87 

0.74 

3.29 

0.99 

2.73 

1.49 

2  29 

1.54 

1.67 

1.35 

2  36 

1.34 

2.60 

1.30 

3.07 

0.92 

1.47 

0.74 

1.43 

0.76 

1.73 

1.10 

2.14 

0.95 

1.20 

1.01 

1.93 

1.36 

2.20 

1.26 

2  50 

0.94 

2.47 

1.30 

2.29 

0.99 

2.00 

1.56 

2  79 

1.42 

1.53 

0.64 

2,00 

0.88 

1  47 

0.74 

1.93 

0.73 

1.20 

0.68 

1.86 

0.77 

1.33 

1.18 

2  29 

1.44 

0.33 

0.62 

0.14 

0  36 

0  73 

0.70 

1.71 

1.07 

1.27 

0.80 

2.29 

1.49 

1.33 

0.98 

2  00 

1.24 

Comptroller  Safety 


Mean 

SO 

Mean 

SO 

2.71 

1.44 

1.94 

1.29 

2.57 

1.50 

1.94 

1.53 

1.36 

1.01 

0.75 

1.13 

2.57 

1.55 

2.31 

1.62 

2.93 

1.44 

2.56 

1.31 

2.21 

1.53 

2.88 

1.38 

2.66 

1.70 

2.86 

1.67 

3.14 

1.51 

3.44 

1.26 

264 

1.55 

3.19 

1.47 

1.86 

1.56 

1.38 

1.54 

3.14 

1.03 

1.88 

1.75 

1.93 

0.92 

1.00 

0.52 

1.43 

0.65 

1.06 

0.68 

3.14 

1.23 

3.25 

1.61 

3.14 

1.17 

3.31 

1.89 

1.21 

0.58 

1.44 

1.03 

0.43 

0.85 

0.25 

0.58 

1.00 

0.68 

0.75 

0.86 

0.36 

0.50 

0.75 

1.53 

2.00 

1.11 

2.06 

1.39 

1.79 

0.70 

2.31 

1.30 

0.79 

0.70 

0.56 

1.03 

0.64 

0.50 

0.19 

0.40 

2.50 

1.61 

3  00 

2.10 

0.86 

0.66 

3.00 

1.03 

0.64 

0.74 

0.63 

1.26 

1.07 

0.47 

1.19 

1.52 

2.57 

0  85 

2.00 

0  89 

3.21 

1.25 

2.00 

0.82 

2.93 

0.83 

2.63 

1.63 

2.29 

1.14 

1.88 

1.31 

2  36 

1.22 

2.00 

1.03 

1.57 

0.94 

2.13 

1  26 

3.29 

0.83 

3  81 

1.56 

3  07 

1.14 

3.50 

1.46 

3.29 

1.14 

2.75 

1.39 

4.00 

0.78 

3.56 

1.31 

3.86 

1.10 

3.31 

1.49 

4.43 

0  76 

4  88 

0.34 

3.79 

0.97 

4.13 

1.02 

3.07 

0.92 

2.63 

1.31 

2.57 

0.85 

2  50 

1.46 

3.36 

1.50 

2  25 

1.00 

2.86 

0.86 

3.13 

0.81 

3.50 

1.16 

3.44 

1.15 

1.50 

1.02 

2.56 

1.59 

4.07 

1.14 

4.00 

1.46 

2.50 

1.34 

2  44 

1.55 

2.50 

1.56 

2.00 

1.63 

1.43 

1.45 

2.38 

1.67 

1.64 

1.28 

4.44 

0.69 

1.50 

1.09 

4.38 

0.89 

2.29 

1.59 

2.08 

1.24 

2.07 

1.54 

2.94 

1.57 

1.50 

1.56 

2.00 

1.75 

2.57 

1.02 

2.00 

1.46 

1.79 

0.97 

1.44 

0.73 

3.14 

1.10 

1.88 

1.09 

3.36 

1.28 

0.44 

0.81 

3.64 

1.22 

2.31 

1.14 

3.93 

0.92 

1.38 

1.59 

4.21 

0.89 

1.88 

1.50 

3.21 

1.19 

1.44 

0.89 

2.84 

0.93 

1.36 

0.96 

2.79 

1.25 

0.86 

0.96 

3.07 

1.44 

1.00 

1.37 

2.07 

1.33 

0.06 

0.25 

1.29 

0.73 

0.50 

0.73 

2.50 

0.85 

1.25 

1.44 

2.00 

0.66 

1.25 

1.46 

Security  Supply 


Mean 

SD 

Mean 

SO 

2.62 

1.50 

2.60 

0.64 

2.85 

1.57 

2.30 

1.06 

3.15 

1.34 

1.90 

0.74 

3.38 

1.33 

3.30 

1.06 

3.38 

1.71 

3.30 

1.34 

2.85 

1.57 

2.60 

1.40 

3.69 

1.44 

3.10 

1.73 

3.31 

1.03 

3.50 

1.35 

2.77 

1.42 

3.70 

0.95 

1.69 

1.44 

2.60 

1.14 

3.08 

1.19 

3.30 

1.34 

1.92 

1.32 

2.40 

1.17 

1.69 

1.11 

1.60 

0.92 

3.15 

1.28 

3.80 

1.03 

2.92 

1.61 

3.50 

0.97 

1.92 

1.04 

2.30 

0.95 

1.00 

0.71 

1.10 

0.74 

1.69 

1.49 

2.00 

1.33 

2.23 

1.64 

1.20 

1.23 

2.62 

1.12 

2.40 

0.84 

2.92 

0.76 

2.20 

0.63 

2.08 

1.12 

1.80 

1.03 

1.38 

1.04 

1.20 

1  03 

3.69 

1.49 

3.70 

1.25 

0.92 

1.19 

1.10 

1.10 

2  54 

1.20 

1.00 

0.82 

1.92 

1.38 

2.20 

1.40 

2.08 

1.04 

2.30 

0.67 

2  54 

1.33 

3.20 

1.03 

3.38 

1.56 

3.40 

1.07 

2.92 

1.38 

3.00 

1.05 

3  00 

1.35 

2  90 

0.88 

2  31 

1.11 

2.90 

1.10 

3.38 

1.50 

3.70 

1.25 

3.46 

1.39 

4  10 

0.88 

3.69 

0.85 

4.00 

0  67 

3.69 

0.95 

3.90 

1.29 

3.38 

1.33 

3.60 

1.03 

4.54 

0.66 

4.60 

0.52 

3.85 

0.90 

4.10 

1.20 

2.62 

1.61 

2.90 

1.66 

3.15 

1  07 

2.60 

1.58 

2.38 

1.04 

2.00 

1.05 

3.23 

1.24 

2.90 

0.74 

4.15 

0.69 

4.30 

0.95 

3.23 

1.09 

3.30 

1.25 

4.00 

1.08 

3.90 

1.29 

2.77 

1.42 

3.10 

0.74 

2.54 

1.33 

3.10 

0.57 

2.06 

1.32 

2.20 

0.92 

2.15 

1.28 

2.40 

0.64 

2.06 

1.26 

2  50 

0.53 

1.00 

1.15 

3.20 

1.62 

2.31 

1.60 

2.20 

1.99 

2.48 

1.66 

1.90 

1.79 

2.82 

1.76 

3.10 

0.68 

1.62 

1.04 

1.60 

0.64 

1.62 

0.96 

2.00 

0.62 

1.69 

1.44 

1.90 

0.99 

2.77 

1.36 

2.30 

1.16 

2.23 

1.59 

2.60 

1.03 

2.31 

1.32 

3.30 

1.34 

2.00 

1.22 

2.20 

0.92 

1.92 

1.26 

1.40 

0.70 

1.46 

1.39 

2.10 

0.74 

1.31 

1.18 

2.20 

1.40 

0.36 

0.96 

1.40 

1.65 

0.85 

1.14 

1.20 

0.79 

1.31 

1.25 

2.20 

0.79 

1.36 

1.12 

2.00 

062 

Overall 


Mean 

SO 

2.62 

1.42 

2.51 

1.49 

1.66 

1.32 

2.77 

1.56 

2.96 

1.41 

2.71 

1.45 

3.00 

1.55 

3.26 

1.36 

3.00 

1.55 

2.11 

1.63 

2.74 

1.37 

1.63 

1.11 

1.52 

0.96 

3.21 

1.36 

3.10 

1.47 

1.89 

1.09 

0.76 

0.81 

1.30 

1.13 

1.05 

1.36 

2.15 

1.06 

2.13 

0.97 

1.21 

1.13 

0  76 

0.79 

3  30 

1.60 

1  34 

1.25 

1.24 

1.30 

1  70 

1.45 

2.22 

0.93 

2.61 

1.21 

3  05 

1.17 

2.27 

1  23 

2.46 

1.15 

2.20 

1.05 

3.55 

1.24 

3  41 

1.37 

3.32 

1.16 

3.82 

1  00 

3  55 

1  23 

4  49 

0  76 

3.88 

1.08 

2  84 

1.40 

2  60 

1.21 

2.48 

1  26 

2.82 

1.06 

3.90 

1.07 

2  48 

1.39 

4.09 

1.14 

2.62 

1.27 

2.37 

1.37 

2.05 

1.51 

2.43 

1.52 

2.43 

1  39 

2.06 

1.52 

2.45 

1.59 

1.98 

1.56 

2.62 

1.29 

1.55 

0  83 

2.09 

1.11 

1.71 

1.46 

2.62 

1.25 

2.48 

1  48 

2.70 

1.56 

2.04 

1.12 

1.79 

0.99 

1.67 

1.17 

1.63 

1.49 

066 

1.17 

1.02 

0.94 

1.77 

1.25 

1.63 

1.15 
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TASK  IMPORTANCE  RATINGS 


Administration 

Civil  Englnaar 

Comptrollar 

Safaty 

Sacurlty 

Supply 

Ovarall 

Maan 

SD 

Maan 

SD 

Maan 

SD 

Maan 

SD 

Maan 

SD 

Maan 

SD 

Maan 

SD 

3.07 

0.80 

3.86 

0.36 

3.07 

0.83 

2.75 

1.24 

3.31 

1.11 

2.70 

1.06 

3.13 

0  99 

3.07 

0.80 

3.79 

0.58 

3.21 

0.89 

2.63 

1.54 

3.08 

1.19 

3.20 

1.14 

3.15 

1.10 

2.87 

1.51 

2.00 

1.24 

2.29 

1.59 

1.00 

1.59 

3.69 

0.48 

2.50 

1.35 

2  34 

1.57 

2,67 

1.40 

3.43 

0.85 

3.14 

0.95 

2.38 

1.67 

3.23 

0.83 

3.00 

0.94 

2.95 

1.21 

3.07 

0.88 

3.14 

0.95 

2.93 

0.83 

3.08 

1.18 

3.08 

1.19 

3.00 

0.82 

3.05 

0.97 

2.80 

0.94 

2.21 

1.53 

1.93 

1.44 

2.83 

1.09 

2.62 

1.19 

3.10 

0.74 

2.52 

1.22 

2.47 

1.19 

2.64 

1.22 

2.07 

1.38 

2.58 

1.09 

2.69 

0.75 

2.80 

1.14 

2.52 

1.14 

2.73 

1.10 

3.71 

0,47 

3.00 

0.88 

3.44 

0.61 

3.23 

0.83 

3.70 

0.48 

3.28 

0.86 

2  33 

1.40 

3.71 

0.61 

2.21 

0.97 

3.13 

1.02 

2.92 

1.12 

3.10 

0.99 

2.89 

1.14 

2.27 

1.71 

3.57 

0.65 

1.79 

1.42 

1.89 

1.62 

2.00 

1.53 

2.70 

0.95 

2.30 

1.50 

3.53 

0.83 

2.86 

1.29 

3.36 

0.63 

2.88 

1.63 

3.15 

1.14 

3.10 

1.10 

3.15 

1.16 

2  87 

1.36 

2.36 

1.50 

3.50 

0.65 

2.68 

1.45 

2.62 

1.39 

2.60 

1.23 

2.84 

1.33 

3.53 

113 

2  57 

1.34 

3.71 

0.63 

3.06 

1.48 

2.85 

1.57 

2.60 

1.14 

3.11 

1.31 

3.40 

0.74 

3.14 

1.03 

2.71 

1.07 

3.06 

1.39 

2.77 

1.17 

3.50 

0.53 

3.09 

1.06 

3  13 

0.83 

3.00 

1.30 

2.86 

0.77 

2.61 

1.47 

2.92 

1.12 

2.90 

0.88 

2.94 

1.08 

3.93 

0.26 

2.71 

1.33 

2.93 

0.92 

2.86 

1.41 

3.08 

1.32 

3.70 

0.67 

3.18 

1.15 

2.67 

1.45 

0.86 

1.17 

0.43 

0.65 

0.56 

1.36 

2.08 

1.50 

2.10 

1.60 

1.40 

1.56 

2.67 

1.35 

1.00 

1.11 

1.14 

1.17 

1.56 

1.82 

2.31 

1.44 

2.50 

1.51 

1.83 

1.53 

1  60 

1  59 

0.64 

0.93 

0.43 

0.76 

0.69 

1.40 

2.08 

1.26 

1.80 

1.93 

1.16 

1  44 

3  20 

0.77 

2.50 

1.02 

2.57 

0.76 

3.13 

1.36 

3.23 

1.17 

3.40 

0.70 

2.99 

1.04 

3.20 

0.77 

2.29 

0.99 

2  29 

0.83 

3.19 

1.11 

3.38 

0.77 

3.20 

0.79 

2.91 

0.96 

2  27 

1.44 

0  86 

1.03 

1.43 

1.34 

1.06 

1.69 

2.15 

1.14 

2.50 

1.18 

1.66 

1  44 

1.47 

1.30 

0  86 

1  03 

1.00 

1.24 

0.44 

0.96 

1.54 

1.27 

1.40 

1.35 

1.09 

1.22 

3  93 

0.26 

3  00 

1.24 

2.79 

1  58 

2  88 

1.75 

3  15 

1.46 

3.60 

0  52 

3.21 

1.32 

1.67 

1  29 

1.14 

1.17 

1.00 

0  78 

3  69 

0.70 

1.38 

1.39 

1.60 

1.85 

1.80 

1.49 

3.27 

1  16 

0.64 

0  84 

0  93 

1.21 

1.00 

1.46 

3.23 

0.73 

1.60 

1.58 

1.77 

1  60 

3  20 

115 

1  57 

1.34 

2.14 

1.03 

1.38 

1.75 

2.00 

1.35 

2.80 

1.03 

2  15 

1.44 

3.13 

0  99 

3  29 

0.91 

3.43 

0.65 

3.06 

1.18 

3.00 

1.15 

3.40 

0.84 

3.21 

0  97 

2  73 

1  33 

3  14 

1.10 

3.50 

0.65 

2.81 

1.17 

2.77 

1  01 

3.40 

0  70 

3.04 

1  06 

3  33 

0.82 

3.14 

0  86 

3.50 

0.85 

2.94 

1.34 

3.15 

1.14 

3.60 
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MEASURES  OF  ASSOCIATION  BETWEEN  TASK  RANKINGS 
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TabteC-1 

AGREEMENT  BETWEEN  PAIRED  DEPARTlttNTB  ON  RANK-ORDERMG  OF  TASKS  BY  FREQUENCY 
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MMy 


Sacurty 


Tau* 

Z** 

Tau 

Z 

Tau 

Z 

Tau 

Z 

Tau 

Z 

Civil  Engineer 

0.39 

4.8 

Comptroller 

0.38 

4.7 

0.51 

6.2 

Safety 

0.53 

6.5 

0.53 

6.5 

0.35 

4.3 

Security 

0.64 

7.8 

0.50 

6.1 

0.39 

4.7 

0.56 

6.9 

Supply 

0.57 

7.0 

0.65 

7.9 

0.51 

6.3 

0.60 

7.3 

0.63 

7.7 

Overall 

0.64 

7.8 

0.70 

8.6 

0.60 

7.3 

0.70 

8.6 

0.71 

8.7 

Supply 

Tau  Z 


0.78  9.6 


*  Kendall's  Tau,  a  nonparametric  test  of  statistical  association. 

**  Z-score  transformation  of  Kendall's  Tau  to  allow  interpretation  as  a  normal  distribution. 


Table  C- 2 

AGREEMENT  BETWEEN  PAIRED  DEPARTMENTS  ON  RANK-ORDERING  OF  TASKS  BY  IMPORTANCE 


Administration 
Tau*  Z** 

CM  Engineer 
Tau  Z 

vQmpirowr 
Tau  Z 

Safety 

Tau  Z 

Security 
Tau  Z 

Civil  Engineer 

0.24 

2.9 

Comptroller 

0.21 

2.6 

0.40 

4.9 

Safety 

0.41 

5.0 

0.30 

3.7 

0.14 

1.7 

Security 

0.60 

7.4 

0.36 

4.4 

0.21 

2.6 

0.47 

5.8 

Supply 

0.43 

5.3 

0.45 

5.5 

0.32 

3.9 

0.33 

4.1 

0.42  5.2 

Overall 

0.59 

7.2 

0.58 

7.1 

0.48 

5.9 

0.55 

6.7 

0.64  7.8 

Supply 
Tau  Z 


0.58  7.1 


*  Kendall's  Tau.  a  nonparametric  test  of  statistical  association. 

*•  Z*score  transformation  of  Kendall's  Tau  to  allow  interpretation  as  a  normal  distribution. 
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AGREEMENT  AMONG  DEPARTMENT  HEADS  ON  RANK-ORDERING 
OF  TASKS  BY  FREQUENCY  AND  BIPORTANCE 


Mmramuon 

CM  Engineer 

Oomplohr 

Safety 

Sacurty 

aw'y 

Tau* 

Z*' 

Tau 

Z 

Tau 

Z 

Tau 

Z 

Tau 

Z 

Tau 

Z 

0.50 

6.2 

0.54 

6.6 

0.46 

5.6 

0.62 

7.6 

0.54 

6.6 

0.51 

6.3 

Overall  0.49  6.0 


*  Kendall's  Tau,  a  nonparametric  test  of  statistical  association. 

**  Z-score  transformation  of  Kendall's  Tau  to  allow  interpretation  as  a  normal  distribution. 
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Table  C -4 


AGREEMENT  AMONG  DEPARTMENT  HEADS  AT  VARKXJS  TYPES  OF 
COMMANDS  ON  RANK-ORDERMQ  OF  TASKS  BY  FREQUENCY 

ttavta  Stations  Naval  Air  Stations 


Tau* 

Z** 

Tau 

Z 

Naval  Air  Stations 

0.79 

9.7 

Other  Baaea/Statlons 

0.83 

10.2 

0.79 

9.6 

*  Kendall’s  Tau,  a  nonparametnc  test  of  statistical  association. 

“  Z-score  transformation  of  Kendall's  Tau  to  allow  interpretation  as  a  normal  distribution. 


Table  C-5 

AGREEMENT  AMONG  DEPARTMENT  HEADS  AT  VARKHJS  TYPES  OF 
COMMANDS  ON  RANK-ORDERING  OF  TASKS  BY  NPORTANCE 

Neva!  Stations  Naval  Air  Stations 


Tau* 

Z** 

Tau 

Z 

Naval  Air  Stations 

0.74 

9.0 

Other  Bases/Stations 

0.58 

7.2 

0.61 

7.4 

*  Kendall's  Tau.  a  nonparametnc  test  of  statistical  association. 

**  Z-score  transformation  of  KendalTs  Tau  to  attow  interpretation  as  a  normal  distribution. 
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APPENDIX  D 


COMPUTER  SUPPORT  NEEDS  REPORTED  BY  DEPARTMENT  HEADS 


D-0 


COMPUTER  SUPPORT  NEEDS  REPORTED  BY  DEPARTMENT  HEADS 


The  following  information  was  compiled  from  comments  made  by  department 
heads  during  the  interviews.  The  list  identifies  areas  where  computer  and  decision 
support  is  needed  by  base  and  station  department  heads. 


Administration 

o  Tracking  correspondence  throughout  command 
o  Maintaining  and  revising  instructions,  notices 
o  Maintaining  manning  and  personnel  data: 
manning  requirements 
retention  rates 
security  clearances 
status  of  personnel  advances 
personnel  location  on  base 
personnel  medical  status 

o  Sharing  of  personnel  data  with  appropriate  departments 
o  Method  to  tally  information  automatically 
o  Statistical  analysis  tools 
o  Electronic  mail 


Civil  Engineering /Public  Iforfcs 

o  Tracking  building  and  maintenance  projects 

o  Timely  access  to  job  status  information 

o  Network  with  supply  MIS  information 

o  Real-time  financial  status  information 

o  Automation  of  blueprints,  digitized  floor  plans,  work  orders 

o  Assistance  in  prioritizing  projects 

o  Improved  quality  of  annual  inspection  summary  report 


Comptroller 

o  Timely  and  accurate  data  concerning  budget  execution 
o  Ability  to  respond  to  larger  number  of  budget  requests 
o  Ability  to  respond  to  larger  number  of  ADP  equipment  requests 
o  Need  for  MIS  interface  between  comptroller  and  supply 
o  More  timely  and  accurate  requisition  status  information 
o  Timely  data  to  calculate  operating  targets  (OPTARS) 
o  Graphics  capabilities 


I 
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Safety 


o  More  timely,  accurate  injury  data 
o  Ability  to  link  with  supply,  personnel  data 
o  Track  progress  on  OSHA -mandated  safety  tasks 
o  Improve  monitoring  of  haaardons  materials 
o  Respond  faster  to  inspection  data  reaaeets 
o  Monitor  larger  number  of  incident  reports 
o  Track,  retrieve,  summarise  many  kinds  ef  data: 
training  rosters 
mishap  vehicle  reports 
deficiency  notices 
hazards  communication  log 
log  of  occupational  illaase/injnry 


Security 

o  Tracking  base  entry  security  information 
o  Tracking  base  security  force  training,  qualifications 
o  Monitoring  of  criminal  activity  on  base  by  location,  suspects 
o  Tracking  additional  security  information: 
prior  security  violations 
DW1  violations 
base-barred  drivers 
security  force  information 
security  qualifications  training 

o  Monitor  and  easily  retrieve  many  kinds  of  security  information: 
criminal  activity  file 
suspect  file 
on-base  weapons  file 
traffic  violation  file 

o  Statistical  analysis  capabilities  to  answer  questions  concerning  base  security,  such  as: 
How  do  shifts  in  the  location  of  security  personnel  affect  incidence  frequency? 
What  is  the  pattern  of  incidents  throughout  the  year? 
o  Network  with  administration,  supply,  safety 
o  Network  with  other  bases  on  security  information 

o  Standard  formats  for  incidents  reports  (in  order  to  force  common  structure, 
encourage  complete  reporting) 


Supply 

o  Automated  procurement  process 
o  Network  with  comptroller 

o  Fast  and  easy  connection  with  larger  automated  systems 
o  Tracking  of  requisitions 

o  Maintaining  computerized  inventory  of  supply  line  items 
o  Tracking  supply  inventory  location 
o  Tools  to  assist  in  optimizing  warehouse  space 
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MIS  EVALUATION  INDICATORS  REPORTED  BY  DEPARTMENT  HEADS 


The  following  information  lists  department-specific  evaluation  indicators  that 
could  be  used  to  assess  the  implementation  and  effectiveness  of  computer  support 
systems. 

Administration 

Indicators  given  a  high  priority  by  a  majority  of  administration  department  heads 
concerned  feedback  from  superion  and,  to  a  lesser  degree,  work  quality,  speed,  and 
timeliness.  Those  specifically  mentioned  included 

o  Speed  and  timeliness  in  preparation  of  reports,  briefing  materials,  decision 
papers,  and  training  materials, 
o  Accuracy  of  data  provided  to  decision  makers, 
o  Ease  of  access  to  and  availability  of  information, 
o  Elimination  of  double  entry  and  file  storage  of  data, 
o  Improved  response  time  for  command  correspondence  (increased  timeliness) 
and  status  reports. 

o  Quality  of  work  output,  such  as  reduction  in  number  of  errors  in  routine 
reports  and  internal/external  correspondence,  and  consequent  reduction  in 
number  of  times  work  is  redone. 

o  Overall  quality  of  format  and  content  of  reports,  briefing  materials,  and  other 
documents. 

o  Meaningfulness,  completeness,  and  usefulness  of  data  or  information  available, 
o  Reduction  in  number  of  user  or  client  complaints. 

o  Extent  to  which  department  members  are  available  to  work  directly  towards 
achieving  department  needs  and  command  mission  in  a  cost-effective  manner. 

Comptroller 

Performance  indicators  most  frequently  discussed  generally  referred  to  accuracy 
and  timeliness  of  budgets  and  degree  of  compliance  with  budget  targets.  Specifically 
mentioned  were: 

o  Overspending  versus  underspending. 

o  Extent  of  satisfaction/dissatisfaction  expressed  by  other  department  heads 
(DHs). 

o  Extent  of  concern  expressed  by  CO. 
o  Retention  of  personnel, 
o  Extent  of  cost  saving  actions  by  other  DHs. 

o  Reduction  in  need  for  labor  hours  spent  in  rechecking  and  reentering  financial 
and  budgetary  data. 

o  Capacity  to  store  and  analyze  financial  investigative  data, 
o  Clarity,  timeliness,  and  meaningfulness  of  budgetary  data  presented  to 
CO/XO/DHs. 

o  Number  of  report  deadlines  met. 
o  Speed  of  access  to  status  of  requisition  requests. 

o  Flexibility  and  responsiveness  to  changes  in  funds  available  or  unexpected 
nonbudgeted  requirements. 
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o  Timeliness  and  status  of  host-tenant  agreements, 
o  Feedback  from  client  DHs  or  tenant  commands, 
o  Speed  and  accuracy  in  recognizing  trends. 

o  Number  of  labor  hours  spent  on  routine  reports  and  correspondence, 
o  Total  bottom  line  costs  of  typical  base/installation  jobs, 
o  Speed  and  accuracy  of  procurement  actions, 
o  Extent  of  compliance  with  regulations  and  statutes. 

Civil  Engineering /Public  Works 

Most  frequently  indicated  measures  of  department  performance  and  useful 
measures  of  an  MIS  related  to  customer  satisfaction  or  feedback,  or  timeliness  of  work 
performed.  Specific  indices  included: 

o  Timeliness  of  completed  tasks. 

o  Extent  to  which  procedural  improvements  led  to  benefits  exceeding  costs, 
o  Timeliness  of  response  to  customer  requests, 
o  Number  of  work  area  inspections  completed  in  a  given  period, 
o  Turnaround  time,  amount  of  lost  time,  scheduling  time,  resheduling  flexibility, 
o  Number  of  jobs  completed, 
o  Number  of  jobs  backlogged. 

o  Average  period  of  time  from  receipt  of  request  to  final  signoff  and 
replenishment  of  parts  and  materials  used, 
o  Timeliness  and  ease  of  initiating,  logging,  and  assigning  work  orders, 
o  Number  of  lapsed  contracts, 
o  Number  of  letters  of  appreciation  and  complaints, 
o  Housing  occupancy  rates. 

o  Availibility  of  base  transportation  and  percentage  of  downtime  of  base  vehicles, 
o  Percentage  of  downtime  of  maintenance  and  other  equipment, 
o  Extent  of  compliance  with  OPTARS. 
o  Accuracy  and  timeliness  of  data  available  and  used. 

o  Clarity,  feasibility,  appropriateness,  and  comprehensiveness  of  department  plan 
for  completing  its  mission. 

Safety 


Most  frequently  identifed  indicators  of  department  performance  were  ratio  of 
labor  hours  devoted  to  field  inspections  versus  office-based  activities/paperwork, 
timeliness  of  response  to  inspection  requests,  number  and  thoroughness  of  inspections, 
and  number  of  critical  incidents  or  accidents.  Department  heads  noted  that  superior 
performance  by  the  department  may  have  practical,  beneficial  consequences  that  do  not 
become  manifest  until  many  months  or  years  later.  Other  performance  measures 
mentioned  included: 

o  Feedback  from  other  departments, 
o  Extent  of  compliance  with  safety  standards, 
o  OSHA  reports  and  inspection  results, 
o  Number  of  discrepancies  identified  and  abated, 
o  Timeliness  and  accuracy  of  inspection  reports, 
o  Number  of  labor  hours  lost  to  accidents, 
o  Dollars  spent  on  workers'  compensation  and  disability  claims, 
o  Increased  amount  of  useful,  accurate,  relevant  data. 
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Security 


Most  frequently  discussed  performance  measures  stressed  feedback  from  other 
departments,  timeliness  in  responding  to  emergency  calls,  and  productivity,  as  indicated 
by  numbers  of  contacts  or  incidents  dealt  with  per  shift.  Other  indicators  identified 
included: 

o  Number  of  complaints. 

o  Courtroom  success  rate. 

o  Responsiveness  to  requests  for  information. 

o  Number  of  reports  received  and  investigated. 

o  Number  and  seriousness  of  illegal  incidents  on  base. 

o  Time  available  for  field  police  functions. 

o  Accuracy  and  completeness  of  incident  and  investigative  reports. 

Supply 

Most  frequently  discussed  performance  measures  related  to  timeliness  of 
response,  customer  feedback,  plus  the  number,  speed  and  accuracy  of  requisition 
requests  successfully  processed.  Other  indicators  include± 

o  Extent  of  data  entry  duplication, 
o  Number  of  customer  complaints, 
o  Accuracy  of  inventory  data, 
o  Amount  of  compliance  monitoring, 
o  Accuracy  in  identifying  ordering  trends, 
o  Extent  of  backlogged  orders. 
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